Node will likely end up with multiple ways to disambiguate modules. Until then, you might dig https://npmjs.com/esm. No .mjs required.
The `esm` loader allows specifying a parse goal pragma as one of several ways to disambiguate source – https://npmjs.com/esm. Node will likely end up needing more than just an extension to disambiguate as well.
I know styfle is aware, but for others, you can unlock named exports of CJS modules with @std/esm: https://github.com/standard-things/esm https://medium.com/web-on-the-edge/es-modules-in-node-today-...
npm5 and 5.1 has improved performance significantly so that it's comparable with yarn.
The TS response makes sense in light of the other issues your desired behavior would cause.
Naw, Lodash is modular. You can cherry-pick its modules. It's less than 716 bytes (with lodash-webpack-plugin).
You might be able to fix that with something like babel-plugin-lodash which can be ran over your code (and deps) to enforce cherry-picking across the board. https://github.com/lodash/babel-plugin-lodash
Not smell just semver – http://semver.org/
This! Lodash turns 5 in 4 months :)
I dig Babel 6. I'm glad they took the major bump, which allows breaking changes, to improve things. The major bump means it's opt-in, so folks can continue to use the older version without breaking their workflow.
:clap:
You might dig lodash-bound – Enables chained lodash functions with ES bind (::) syntax https://github.com/elado/lodash-bound
You might dig mudash – Lodash wrapper providing immutable.js support https://github.com/brianneisler/mudash
If you dig immutable, auto-curried, data-last methods there's also lodash/fp modules – https://github.com/lodash/lodash/wiki/FP-Guide
Yep, as well as outside donations – https://jquery.org/ Every bit helps.
Creator of Lodash here. From my experience the foundation is a pretty chill, hands off, non-profit. I sought out and voluntarily joined the Dojo Foundation early in Lodash's development (~2013). At the time the Dojo…
No-trololo: Lodash is modular so you can use cherry-pick the methods you want. There's plugins to make it easier and further reduce bundle sizes. https://github.com/lodash/babel-plugin-lodash…
lodash.throttle is a standalone zero-dependency package of just the throttle module. The `lodash` package is a collection of modules one of which is `lodash/throttle`. You can generally get smaller bundles using…
No worries, lodash/debounce can be reduced further with babel+webpack plugins. Assuming the current setup of babel+webpack the difference between your naive version is just ~0.5 kB.
Congrats!
There's no hard requirement for babel-polyfill or babel-runtime. Babel works great without shims in modern enviros (I don't use shims in my projects).
Neither Rollup nor Webpack 2 will tree-shake Lodash properly. The best option at the moment is babel-plugin-lodash.
Related: https://twitter.com/jdalton/status/754474672977096704.
BTW there's lodash/fp modules too: https://github.com/lodash/lodash/wiki/FP-Guide https://simonsmith.io/dipping-a-toe-into-functional-js-with-... https://medium.com/@jdalton/just-a-heads-up-the-lazy-js-benc...
Lodash methods handle things like String#match which returns array/null. More for avoiding guard scaffolding than for undefined behavior.
Node will likely end up with multiple ways to disambiguate modules. Until then, you might dig https://npmjs.com/esm. No .mjs required.
The `esm` loader allows specifying a parse goal pragma as one of several ways to disambiguate source – https://npmjs.com/esm. Node will likely end up needing more than just an extension to disambiguate as well.
I know styfle is aware, but for others, you can unlock named exports of CJS modules with @std/esm: https://github.com/standard-things/esm https://medium.com/web-on-the-edge/es-modules-in-node-today-...
npm5 and 5.1 has improved performance significantly so that it's comparable with yarn.
The TS response makes sense in light of the other issues your desired behavior would cause.
Naw, Lodash is modular. You can cherry-pick its modules. It's less than 716 bytes (with lodash-webpack-plugin).
You might be able to fix that with something like babel-plugin-lodash which can be ran over your code (and deps) to enforce cherry-picking across the board. https://github.com/lodash/babel-plugin-lodash
Not smell just semver – http://semver.org/
This! Lodash turns 5 in 4 months :)
I dig Babel 6. I'm glad they took the major bump, which allows breaking changes, to improve things. The major bump means it's opt-in, so folks can continue to use the older version without breaking their workflow.
:clap:
You might dig lodash-bound – Enables chained lodash functions with ES bind (::) syntax https://github.com/elado/lodash-bound
You might dig mudash – Lodash wrapper providing immutable.js support https://github.com/brianneisler/mudash
If you dig immutable, auto-curried, data-last methods there's also lodash/fp modules – https://github.com/lodash/lodash/wiki/FP-Guide
Yep, as well as outside donations – https://jquery.org/ Every bit helps.
Creator of Lodash here. From my experience the foundation is a pretty chill, hands off, non-profit. I sought out and voluntarily joined the Dojo Foundation early in Lodash's development (~2013). At the time the Dojo…
No-trololo: Lodash is modular so you can use cherry-pick the methods you want. There's plugins to make it easier and further reduce bundle sizes. https://github.com/lodash/babel-plugin-lodash…
lodash.throttle is a standalone zero-dependency package of just the throttle module. The `lodash` package is a collection of modules one of which is `lodash/throttle`. You can generally get smaller bundles using…
No worries, lodash/debounce can be reduced further with babel+webpack plugins. Assuming the current setup of babel+webpack the difference between your naive version is just ~0.5 kB.
Congrats!
There's no hard requirement for babel-polyfill or babel-runtime. Babel works great without shims in modern enviros (I don't use shims in my projects).
Neither Rollup nor Webpack 2 will tree-shake Lodash properly. The best option at the moment is babel-plugin-lodash.
Related: https://twitter.com/jdalton/status/754474672977096704.
BTW there's lodash/fp modules too: https://github.com/lodash/lodash/wiki/FP-Guide https://simonsmith.io/dipping-a-toe-into-functional-js-with-... https://medium.com/@jdalton/just-a-heads-up-the-lazy-js-benc...
Lodash methods handle things like String#match which returns array/null. More for avoiding guard scaffolding than for undefined behavior.