News for hackers. Stuff that matters.

jdd

Re:ECMAScript modules in Node.js: the new plan on Thursday December 27, 2018 @10:43AM (#18770089)
Node will likely end up with multiple ways to disambiguate modules. Until then, you might dig https://npmjs.com/esm. No .mjs required.
Re:ECMAScript modules in Node.js: the new plan on Thursday December 27, 2018 @10:24AM (#18769923)
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.

Re:Using ES modules natively in Node.js on Thursday September 14, 2017 @01:31PM (#15250317)
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-...

Re:Npm v5.1.0 Released on Monday July 10, 2017 @05:15PM (#14739756)
npm5 and 5.1 has improved performance significantly so that it's comparable with yarn.
Re:Ask HW: What is the state (for you) of CoffeeScript? on Saturday April 15, 2017 @11:49PM (#14124221)
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).
Re:Webpack 2, RC 7 on Friday January 20, 2017 @05:31PM (#13447511)
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

Re:JavaScript frameworks and topics to learn in 2017 on Monday December 19, 2016 @02:39PM (#13214349)
Not smell just semver – http://semver.org/
Re:JavaScript frameworks and topics to learn in 2017 on Monday December 19, 2016 @02:28PM (#13214259)
This! Lodash turns 5 in 4 months :)
Re:Dear JavaScript on Thursday December 08, 2016 @12:11AM (#13128548)
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.

Re:Dear JavaScript on Wednesday December 07, 2016 @03:04PM (#13125713)
:clap:
Re:Zaphod: Clojure's API for JavaScript's Data Structures on Sunday December 04, 2016 @05:00PM (#13102009)
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

Re:A small dive into, and rejection of, Elm on Wednesday November 09, 2016 @05:51PM (#12915617)
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 Foundation was the only JS foundation I knew of that was open to outside projects (the jQuery Foundation was really only for jQuery projects back then). Eventually the Dojo Foundation and the jQuery Foundation merged. It was great! Regardless of the name the foundation has proven valuable. Whether it's CLA management, PR bots, conduct reviews, representation at TC39, help with trademarks, licenses, legal, etc. they've always been friendly and more than happy to help. When possible they also hold events to educate and encourage new open source contributors which is pretty cool!
Re:A Simple JavaScript change to reduce your build size on Friday September 02, 2016 @08:43PM (#12417162)
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

https://github.com/lodash/lodash-webpack-plugin

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 `lodash/xyz` modules over the `lodash.xyz` packages because of plugins like:

https://github.com/lodash/babel-plugin-lodash

https://github.com/lodash/lodash-webpack-plugin

Though in the future lodash-webpack-plugin may support `lodash.xyz` packages too.

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.
Lodash v4 reduced the deps of its individual modularized method packages.

It also offers modules inside the primary package now, e.g. require('lodash/chunk').

There's babel and webpack plugins to make cherry-picking and bundle size optimizations a breeze too.

https://github.com/lodash/babel-plugin-lodash

https://github.com/lodash/lodash-webpack-plugin

Re:Lists of JavaScript methods which you can use natively on Saturday July 02, 2016 @10:31AM (#12022680)
Lodash methods handle things like String#match which returns array/null.

More for avoiding guard scaffolding than for undefined behavior.

You also dig Lodash v4's FP modules

https://github.com/lodash/lodash/wiki/FP-Guide

Webpack 2 or Rollup don't tree-shake Lodash well.

You'll need something like https://github.com/lodash/babel-plugin-lodash.

Lodash follows semver so major changes are opt-in unlike lang level ones though.
I donno, Lodash is missing < 90 R apis where as R is missing > 200 Lodash ones.

Older »