Skip to content
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

[Package Importer] Specs #1952

Merged
merged 65 commits into from
Feb 6, 2024
Merged

[Package Importer] Specs #1952

merged 65 commits into from
Feb 6, 2024

Conversation

jamesnw
Copy link
Contributor

@jamesnw jamesnw commented Oct 30, 2023

@jamesnw jamesnw requested a review from nex3 November 13, 2023 14:18
@@ -35,7 +35,29 @@ it('an empty object means an empty file', () =>

describe('import precedence:', () => {
describe('in sandbox dir', () => {
it('relative file is #1', () =>
it('packageImporter:node is #1', () =>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't relevant to the import precedence that this describe() is testing. These tests verify what happens when there are multiple possible interpretations of the same load. Because the package importer is always absolute (since it has the pkg: scheme), it's never ambiguous with relative, load path, or working-directory loads.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense. I've removed this test here. I added this as the spec specifies that Package Importers are resolved first for the legacy API. Do we need to test that, or perhaps, is there really a way to test that, as there can't be conflicts?

js-api-spec/importer.test.ts Show resolved Hide resolved
js-api-spec/sandbox.ts Outdated Show resolved Hide resolved
js-api-spec/node-package-importer.node.test.ts Outdated Show resolved Hide resolved
js-api-spec/node-package-importer.node.test.ts Outdated Show resolved Hide resolved
js-api-spec/node-package-importer.node.test.ts Outdated Show resolved Hide resolved
js-api-spec/node-package-importer.node.test.ts Outdated Show resolved Hide resolved
js-api-spec/node-package-importer.node.test.ts Outdated Show resolved Hide resolved
js-api-spec/node-package-importer.node.test.ts Outdated Show resolved Hide resolved
@jamesnw jamesnw requested a review from nex3 November 15, 2023 18:48
@jamesnw jamesnw marked this pull request as ready for review November 15, 2023 18:48
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nex3 I needed to make this change after merging Shared Resources into node-embedded-host, as all async tests were failing. I think this is correct now (the callback can be async, so we need to await it, so that the finally doesn't happen before the callback resolves).

However, it seemed worth flagging with you because the async dart-sass tests did not fail, and the node-embedded-host tests did not fail until after merging in Shared Resources, and we weren't able to track down any cause for this difference.

Copy link
Contributor

@ntkme ntkme Jan 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be that functions with FutureOr<T> return type in dart is not really an async function in JS, but a sync function that may return a Promise or T. This allows the some synchronous code path to be dispatched synchronously, and only code inside the returned Promise is dispatched asynchronously, therefore may lead to different execution order than how a true asynchronous function is dispatched.

Comment on lines 770 to 772
compileString('@use "pkg:foo";', {
importers: [new NodePackageImporter()],
})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should just test new NodePackageImporter() without passing it to compileString() now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in oddbird@b18ff2c

@jamesnw jamesnw requested a review from nex3 February 1, 2024 17:27
@nex3 nex3 merged commit 831297e into sass:main Feb 6, 2024
7 checks passed
@nex3 nex3 deleted the feature.package-importer branch February 6, 2024 22:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants