Files
coffeescript/documentation/sections/contributing.md
Geoffrey Booth f6d63776c3 ES module version of compiler for use in browsers; dynamic import() docs; revised Stage 3 policy (#5177)
* Build both a legacy and modern browser compiler

* Dynamic import example and documentation

* Update the docs to use the modern browser compiler if the browser supports it

* Update policy regarding Stage 3 features

* This never made sense, and assigning a string to index 0 *of a string* throws in Module mode (and silently does nothing in Script mode) so remove this unneeded code that throws when compiling `fn for i from from iterable` in Module mode

* Have browser-based tests use the ES module version if supported

* Simplify building logic

* Update output

* For the ES module version of the browser compiler, don't automatically attach the runScripts event handler

* Consistent comments

* Fix comment
2019-03-26 23:55:31 -07:00

1.9 KiB
Raw Permalink Blame History

Contributing

Contributions are welcome! Feel free to fork the repo and submit a pull request.

Some features of ECMAScript are intentionally unsupported. Please review both the open and closed issues on GitHub to see if the feature youre looking for has already been discussed. As a general rule, we dont support ECMAScript syntax for features that arent yet finalized (at Stage 4 in the proposal approval process) or implemented in major browsers and/or Node (which can sometimes happen for features in Stage 3). Any Stage 3 features that CoffeeScript chooses to support should be considered experimental, subject to breaking changes or removal until the feature reaches Stage 4.

For more resources on adding to CoffeeScript, please see the Wiki, especially How The Parser Works.

There are several things you can do to increase your odds of having your pull request accepted:

  • Create tests! Any pull request should probably include basic tests to verify you didnt break anything, or future changes wont break your code.
  • Follow the style of the rest of the CoffeeScript codebase.
  • Ensure any ECMAScript syntax is mature (at Stage 4, or at Stage 3 with support in major browsers or runtimes).
  • Add only features that have broad utility, rather than a feature aimed at a specific use case or framework.

Of course, its entirely possible that you have a great addition, but it doesnt fit within these constraints. Feel free to roll your own solution; you will have plenty of company.