added support for transpiling ESNext #10
Conversation
FND
commented
Jun 27, 2020
•
FND
commented
- discuss Browserslist support (faucet-js has a more abstract/implicit mechanism, allowing for automatic discovery)
- tooling for dependency management
- CWD issues (see commit description)
caveats: * much like with CommonJS globbing, `exclude` assumes `node_modules` is relative to the current working directory (as evidenced by awkward directory management in the corresponding test) * requires three dependencies (@rollup/plugin-babel, @babel/core and @babel/preset-env), so we'll probably need to introduce meta-packages to avoid burdening users with such internal details
FND
force-pushed
the
transpiling
branch
2 times, most recently
from
d8f5dec to
c0ded11
Compare
this resolves the dependencies-management issue (cf. previous commit; 69a2bc2) opting into features like this is pretty much why we designed extensible configuration the way we did creating a separate repository for this plugin didn't seem warranted and would have complicated testing
There was a problem hiding this comment.
-
tests are red because Beatdown v1.0.2 is yet to be released - locally we can simulate this by installing v1.0.1 instead and upgrading that manually (i.e.
rm -r node_modules/beatdown/lib; cp -R lib node_modules/beatdown/)yes, that's awkward, but I don't expect this kinda issue to re-occur frequently
-
now that we have multiple packages in the same repo, we'll need to port faucet's tools for managing meta-packages (updating dependencies and automating releases)
| this.id = id; | ||
| this.ref = ref; | ||
| this.config = config; | ||
| if(supplier) { | ||
| this.supplier = supplier; | ||
| } |
There was a problem hiding this comment.
having to be aware of this (rather subtle distinction) here just so we can pass it through to loadExtension is somewhat unfortunate, but probably the inevitable cost of the priority of constituencies?
| @@ -1,5 +1,6 @@ | |||
| "use strict"; | |||
|
|
|||
| exports.report = console.error; | |||
| exports.warn = msg => void console.error(`WARNING: ${msg}`); | |||
There was a problem hiding this comment.
note: we can't replace console.error with report here (for encapsulation) because of the way consoleMock works in tests - le sigh
| import: "default" | ||
| }, config, "beatdown-babel"); | ||
| // ensure controlled error handling for implicit dependency | ||
| plugin._load(PRESET_ENV); |
There was a problem hiding this comment.
this is a bit awkward, but necessary (again: priority of constituencies)
however, it does raise the question whether that method should be prefixed with an underscore: it's not actually private then, is it? yet this seems like a rare edge case, so arguably the plugin is consciously relying on internal functionality for which we don't officially provide any guarantees
| //* `exclude` (optional) is a list of modules for which to skip transpilation | ||
| // (e.g. `exclude: ["jquery"]`, perhaps due to the respective library's | ||
| // distribution already being optimized for ES5) | ||
| module.exports = function generateTranspiler({ browsers, exclude }) { |
There was a problem hiding this comment.
a) is that function name still appropriate, given that it returns a Beatdown plugin now? (cf. usage in tests)
b) s/browsers/targets/? valid queries include "current Node", so "browsers" always seemed misleading here - though "targets" seems unhelpfully generic
