You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The more time goes on, the more I'd like to investigate using ES6 modules, rather than CommonJS. This would drastically affect the internals of this plugin, but ultimately it is the right direction to go in the long run.
I was previously thinking that I'd implement #17 by analyzing the CommonJS outputs, but kept running into blockers due to it's less-than-static nature. I recently discovered that rollup/webpack only perform tree-shaking on ES6 modules, since they are static by definition. (this drastically reduces the complexity)
All in all, I'm not sure what the right approach here is. The general use-case has been relying on code published to npm, which is generally pre-compiled to CommonJS. I also don't want to become too opinionated by bundling babel directly here to support the ES6/CommonJS divide.
It looks like rollup relies on jsnext:main in a package.json to reference a file that uses import and export, but I'm worried about an already fractured build process that uses npm code that assumes ES6 because of node 4+. But maybe I can piggy-back on the efforts of rollup and others.
Copied from original issue: makojs/js#99
The text was updated successfully, but these errors were encountered:
Apart of removal of unused code, the other awesome thing that these tools do is inline all module definitions. Or in other words, instead of mocking require() module system in the build, they inline the exported stuff, and thus remove the commonjs module system tax, which speeds up load times considerably.
So I'd be pretty excited to have this in mako as well :) But personally I'm unfamiliar how that works in practice in combination with existing stuff in npm, since I haven't really used rollup or webpack yet.
Also, I'm not aware that there is already a consensus on how are ES modules going to work in node. I know there has been a ton of going back and forth between people who want to make it seamless, with those that want a custom extensions like .mjs, and other horrible solutions. I'm afraid this might lead to some clashes later on, but can't give any specifics. Haven't kept up with it 😢.
From @dominicbarnes on November 28, 2016 7:38
The more time goes on, the more I'd like to investigate using ES6 modules, rather than CommonJS. This would drastically affect the internals of this plugin, but ultimately it is the right direction to go in the long run.
I was previously thinking that I'd implement #17 by analyzing the CommonJS outputs, but kept running into blockers due to it's less-than-static nature. I recently discovered that rollup/webpack only perform tree-shaking on ES6 modules, since they are static by definition. (this drastically reduces the complexity)
All in all, I'm not sure what the right approach here is. The general use-case has been relying on code published to npm, which is generally pre-compiled to CommonJS. I also don't want to become too opinionated by bundling babel directly here to support the ES6/CommonJS divide.
It looks like rollup relies on
jsnext:main
in apackage.json
to reference a file that usesimport
andexport
, but I'm worried about an already fractured build process that uses npm code that assumes ES6 because of node 4+. But maybe I can piggy-back on the efforts of rollup and others.Copied from original issue: makojs/js#99
The text was updated successfully, but these errors were encountered: