Repository navigation
[Babel 8] Refactor register cache - #17229
Conversation
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/60734 |
| }); | ||
|
|
||
| let createdAt = this.db.get("created_at"); | ||
| // If the cache is older than 30 days, clear it |
There was a problem hiding this comment.
If I compile something every day for 31st day, on the 31st day will it delate all the cache or the data from the 1t day?
There was a problem hiding this comment.
It will remove all caches.
| "clone-deep": "^4.0.1", | ||
| "find-cache-dir": "condition:BABEL_8_BREAKING ? ^3.3.1 : ^2.0.0", | ||
| "find-cache-dir": "condition:BABEL_8_BREAKING ? ^5.0.0 : ^2.0.0 (esm:default)", | ||
| "lmdb": "condition:BABEL_8_BREAKING ? ^3.2.6 : (esm:open)", |
There was a problem hiding this comment.
Can we make LMDB an optional dependency? The node-lmdb depends on node-gyp-build, which will kick it when the prebuilt binary bindings does not match the user arch. It is likely to happen when we still support a node version that is not supported by the prebuilt.
This opens all sort of install issues because of the tools/libs required and users may not be familiar with them.
See also parcel-bundler/parcel#8152 for an example.
If we make it an optional dependency, users can still use Babel register regardless of node-gyp-errors, though the cache handling is not as efficient as it would be.
There was a problem hiding this comment.
I agree that this is an annoying problem.
But I worry that making it an optional dependency will make almost no one use it.
There was a problem hiding this comment.
I investigated and the pre-built packages released by lmdb support node-api, so the version shouldn't be a problem.
But they do not provide some pre-built packages compared to rollup, such as the lack of Windows x86 and arm.
234aad8 to
d9a779f
Compare
|
I changed it to |
6c2e217 to
8e040f7
Compare
Thought: if the batch cacache is performant, we can use it for the Babel-loader as well. |
|
@JLHwung |
|
@liuxingbaoyu The webpack cache PR was held back because of #16915 (comment), but we don't have an opportunity to debug why the webpack cache is slower than the current babel-loader file cache. |
7838d13 to
fa98620
Compare
|
commit: |
720474d to
0267e1b
Compare
|
|
||
| exports.init = import("@babel/core").then(initialize); | ||
| exports.init = (async function () { | ||
| await import("@babel/core").then(initialize).catch(err => { |
There was a problem hiding this comment.
Can we require(esm) now?
There was a problem hiding this comment.
I forgot we're using light-jest-runner, let me try!
There was a problem hiding this comment.
I suddenly realized that we can use mjs directly in the worker, which greatly simplifies the code.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
nicolo-ribaudo
left a comment
There was a problem hiding this comment.
This looks good to me, but are we still blocked on the babel-loader bug?
|
Yes, I am investigating. |
This also fixes a hidden bug in Babel 8:
process.on("exit", cb)would not be called.