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

vite test ci #1718

Merged
merged 5 commits into from
Dec 21, 2023
Merged

vite test ci #1718

merged 5 commits into from
Dec 21, 2023

Conversation

patricklx
Copy link
Contributor

@patricklx patricklx commented Dec 12, 2023

adds ci tests for vite dev

  • testing: opening /tests/ and checking the tests output
  • fixes optimizer issue

@mansona
Copy link
Member

mansona commented Dec 13, 2023

@patricklx I don't see this running in CI 🤔 are you just working on this to be able to run tests locally?

@patricklx
Copy link
Contributor Author

the target is to be able to run it in ci. this is just the setup for it.
No idea where to setup the ci test here in embroider repo...

@patricklx
Copy link
Contributor Author

@mansona also tests will not work without

import * as EmberTesting from 'ember-testing';
define('ember-testing', () => EmberTesting);

unless we use ember-source 5.6 beta

@mansona
Copy link
Member

mansona commented Dec 13, 2023

No idea where to setup the ci test here in embroider repo...

So everything happens in scenario-tester which you can see in tests/scenarios/*-test.ts. for now I think we could start up a new scenario that would run this

@patricklx
Copy link
Contributor Author

i might need to extract more from my other PR to make this work

@patricklx
Copy link
Contributor Author

If you could setup the scenario, then i can fix the rest :)

packages/vite/src/resolver.ts Outdated Show resolved Hide resolved
@@ -542,12 +542,22 @@ export class Resolver {
}

private *componentJSCandidates(inPackageName: string) {
const extensions = ['.ts', '.gjs', '.gts'];
Copy link
Contributor Author

Choose a reason for hiding this comment

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

vite can handle this files. webpack can also already handle ts files, for gjs/gts a loader could be added

let resolution = await this.resolve(id, importer, {
skipSelf: true,
});
// prevent resolve loop during vite build
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this parts are only needed during vite build. otherwise it will hang

@patricklx
Copy link
Contributor Author

patricklx commented Dec 15, 2023

the tests pass locally when i run them directly in the repo in windows. But through the scenario setup it fails locally as well. Anyway dep optimizer is not working correctly.
Disabled windows for now. Will look into it later again.
@mansona @ef4

@patricklx
Copy link
Contributor Author

@mansona found a fix for windows.

@patricklx patricklx force-pushed the vite-test branch 9 times, most recently from cdb9a41 to fef309d Compare December 18, 2023 22:10
@patricklx patricklx force-pushed the vite-test branch 3 times, most recently from 046eaeb to 13bc884 Compare December 18, 2023 23:18
@patricklx
Copy link
Contributor Author

@mansona this is ready and also shows that its working while also building cached deps

@patricklx patricklx force-pushed the vite-test branch 2 times, most recently from d06ba7b to 212eb9a Compare December 19, 2023 14:01
Copy link
Contributor

@ef4 ef4 left a comment

Choose a reason for hiding this comment

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

Adding the CI test for vite is great. But that can be one PR by itself. The tests in vite-app are already passing on main, so no other changes should be needed to enable the tests in CI.

To make these other changes to core features like PackageCache or module-resolver we need tests showing why they're needed, and to ensure we don't break those cases in the future.

packages/shared-internals/src/package-cache.ts Outdated Show resolved Hide resolved
packages/vite/src/hbs.ts Outdated Show resolved Hide resolved
packages/vite/src/resolver.ts Outdated Show resolved Hide resolved
packages/vite/src/template-tag.ts Outdated Show resolved Hide resolved
packages/vite/src/template-tag.ts Outdated Show resolved Hide resolved
packages/vite/src/template-tag.ts Outdated Show resolved Hide resolved
packages/vite/package.json Outdated Show resolved Hide resolved
@patricklx
Copy link
Contributor Author

patricklx commented Dec 19, 2023

Adding the CI test for vite is great. But that can be one PR by itself. The tests in vite-app are already passing on main, so no other changes should be needed to enable the tests in CI.

To make these other changes to core features like PackageCache or module-resolver we need tests showing why they're needed, and to ensure we don't break those cases in the future.

The tests where not really testing much. Only that it loads... There where issues with decorators and vite build was also not working.
But yes, i can minimise this to only do vite test first on unix only, and extract the rest to other prs like this:
current pr: only enable ci tests
rest:

  • create more tests
  • test windows
  • add gjs/gts entr for tests
  • build (if i cannot find a simple solution)

@@ -30,6 +30,9 @@ export function esBuildResolver(root = process.cwd()): EsBuildPlugin {
let resolution = await resolverLoader.resolver.resolve(request, defaultResolve(build, kind));
switch (resolution.type) {
case 'found':
if (resolution.result?.path?.includes('rewritten-app')) {
Copy link
Contributor Author

@patricklx patricklx Dec 21, 2023

Choose a reason for hiding this comment

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

@mansona I i think i found the real reason we have the optimizer issue.
We call context.resolve in the default resolve here 0aafe02#diff-a6c8071691a61acc68be864b34d3f338fd92e9bf5217c2d12403ac6029bca885R130
with the full absolute path.
which then goes to the vite dep:scan plugin which marks it as external here: https://github.com/vitejs/vite/blob/main/packages/vite/src/node/optimizer/scan.ts#L681

so either we do not call that and check if the id is already resolved in the default resolve
or use e.g resolve from npm or unmark them as external here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i also created a PR on vite as i think its a vite bug: vitejs/vite#15402
lets see

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Btw, this was working in windows without issues... Will verify later again why this is. I suspect the generated path has somr difference in slashes

@patricklx patricklx force-pushed the vite-test branch 3 times, most recently from de8a7d6 to 94977ab Compare December 21, 2023 12:18
@patricklx
Copy link
Contributor Author

@mansona @ef4 this is ready

let resolution = this.nodeResolve(
`${target.packageName}${candidate.prefix}${target.memberName}${candidate.suffix}`,
target.from
);
if (resolution.type === 'real') {
hbsModule = resolution.filename;
hbsModule = candidateSpecifier;
Copy link
Contributor

Choose a reason for hiding this comment

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

This is similar to what we did in #1648. Both are cases where we were rewriting requests to absolute paths, which ends up looking to vite like the user actually typed an absolute path in their import, which gets different behavior than a normal relative- or package-name import.

In this case when we successfully resolve a specifier to a component file to check that it exists, rather than rewriting the request to point directly at that file we rewrite the request to use the specifier that we just successfully resolved.

(This duplicate resolving is only needed when supporting the ambiguity of loose-mode templates. As people migrate to template tag they stop needing it.)

@ef4 ef4 merged commit 2edb355 into embroider-build:main Dec 21, 2023
203 checks passed
@NullVoxPopuli NullVoxPopuli added enhancement New feature or request internal labels Dec 21, 2023
@github-actions github-actions bot mentioned this pull request Dec 21, 2023
@github-actions github-actions bot mentioned this pull request Apr 4, 2024
@github-actions github-actions bot mentioned this pull request Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request internal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants