- Update the package index:
sudo apt update
- Install fingerprint management daemon:
This post was adapted from an earlier Twitter thread.
It's incredible how many collective developer hours have been wasted on pushing through the turd that is ES Modules (often mistakenly called "ES6 Modules"). Causing a big ecosystem divide and massive tooling support issues, for... well, no reason, really. There are no actual advantages to it. At all.
It looks shiny and new and some libraries use it in their documentation without any explanation, so people assume that it's the new thing that must be used. And then I end up having to explain to them why, unlike CommonJS, it doesn't actually work everywhere yet, and may never do so. For example, you can't import ESM modules from a CommonJS file! (Update: I've released a module that works around this issue.)
And then there's Rollup, which apparently requires ESM to be u
| function createStore (reducers) { | |
| var state = reducers() | |
| const store = { | |
| dispatch: (action) => { | |
| state = reducers(state, action) | |
| }, | |
| getState: () => { | |
| return state | |
| } | |
| } |
This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.
In that post I talked about 3 main reasons for moving from require.js to webpack:
Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.
| # Example with basic types | |
| --- | |
| hash: | |
| string: some text | |
| number: 12345 | |
| array_of_bool: [on, off, true, false, yes, no] | |
| ruby symbol: :symbol | |
| array: | |
| - item one | |
| - item two |