-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make sure the absolute path isn't contained in the cache #5900
Conversation
This pull request has been linked to and will mark 1 task as "Done" when merged:
|
Benchmark ResultsKitchen Sink 🚨
Timings
Cold BundlesNo bundles found, this is probably a failed build... Cached BundlesNo bundles found, this is probably a failed build... React HackerNews ✅
Timings
Cold Bundles
Cached Bundles
AtlasKit Editor 🚨
Timings
Cold BundlesNo bundles found, this is probably a failed build... Cached BundlesNo bundles found, this is probably a failed build... Three.js ✅
Timings
Cold BundlesNo bundle changes detected. Cached BundlesNo bundle changes detected. |
} | ||
} | ||
|
||
for (let id of this.globNodeIds) { | ||
let globNode = this.getNode(id); | ||
invariant(globNode && globNode.type === 'glob'); | ||
|
||
if (isGlobMatch(filePath, globNode.value)) { | ||
if (isGlobMatch(filePath, fromProjectPathRelative(globNode.value))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So filePath
here is absolute, but the glob is relative? Won't that not match except if the glob starts with **/
? I was thinking about how to do this for the glob resolver. Should the glob in the invalidation be relative to the project root? If so, then I think we'd need to make it absolute here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
filePath
is also relative here, further up there's
let filePath = fromProjectPathRelative(_filePath);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I ran into #5483 (comment) again, so I guess I'll have to use the absolute paths anyway (to make micromatch happy).
As a workaround, I've downgraded to micromatch 3 for now 😬
c3ba28f
to
c2dc0c0
Compare
) => ProjectPath) & | ||
((projectRoot: FilePath, p: FilePath | void) => ProjectPath | void) & | ||
// $FlowFixMe Not sure how to type properly | ||
((projectRoot: FilePath, p: ?FilePath) => ?ProjectPath) = toProjectPath_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤷♂️
Hi! Great work here. this PR would be a really big deal for CI / deployment environments where the build directory changes between builds. Several orders of magnitude difference. At the moment it seems the Parcel cache uses the absolute directory. |
packages/core/types/index.js
Outdated
@@ -445,10 +445,9 @@ export type DependencyOptions = {| | |||
+meta?: Meta, | |||
+pipeline?: string, | |||
+resolveFrom?: FilePath, | |||
+target?: Target, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was apparently neither used in the plugins nor inside addDependency
I think this is ready. I added a util that verifies that there are no references to the project root inside the cache folder after each cache test. After upgrading the source maps package to the latest release, all the tests pass. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a lot, but from what I can tell LGTM. cc @mischnic to review changes from @devongovett
let b = await runBundle(entries, options); | ||
|
||
await assertNoFilePathInCache( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤩
* v2: (34 commits) Wrap assets recursively when any incoming dependency is wrapped (#6572) Improvements for library targets (#6570) Diagnostic for undeclared external dependencies in library builds (#6564) More bugs (#6567) Don't require `url:` for image transformer (#6565) Remove 'Name already registered with serializer' error (#6566) Fix live bindings and `this` of external CommonJS modules (#6548) JS runtime improvements (#6531) Make sure the absolute path isn't contained in the cache (#5900) Adds '@parcel/diagnostic' to dependencies (#6563) Disable workers with string literals and improve diagnostics (#6536) Bug fixes (#6541) Don't attempt to resolve URLs starting with '#' (#6504) Correctly set worker's output format if not support by environment (#6534) Babel: Recognize peerDependencies in isJSX (#6497) fix setHeaders ordering on dev server (#6500) Graph: Remove Node interface (#6530) Fix TS build script for old Node versions (#6526) Improve library targets (#6517) Fix TypeScript and other sourcemaps by always creating an initial sourcemap (#6472) ...
Seems micromatch 3 and 4 have undocumented behavior differences, So we ignore the version mismatches for now, under the assumption that the specified versions are exhibiting the expected behavior for the packages they are used in. See #5483 (comment) and #5900 (comment)
Depends on #5802
Closes T-870
This should also always use
/
as path separatorsGrepping the absolute path in .parcel-cache didn't yield any results after this change (for a simple test case).
utils.js
in@parcel/core
, no reason to put them into@parcel/utils
if they're not used outside of core.