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

Confusing package.json script interactions #46

Open
ef4 opened this issue Jul 8, 2022 · 2 comments
Open

Confusing package.json script interactions #46

ef4 opened this issue Jul 8, 2022 · 2 comments

Comments

@ef4
Copy link
Contributor

ef4 commented Jul 8, 2022

Out of the box, yarn test at the top-level emits a confusing warning because it runs the test script in every package and the test script in the addon just echos a warning.

Also, the current setup runs linting in CI twice, because it runs both yarn lint as a dedicated step, but also includes linting in the test-app's test script.

@simonihmig
Copy link
Collaborator

Out of the box, yarn test at the top-level emits a confusing warning because it runs the test script in every package and the test script in the addon just echos a warning.

Yes, not quite ideal... we use yarn workspaces run test to automatically run tests for all workspaces. E.g. by adding another test-app, it's tests would run in CI automatically, which otherwise you could easily miss to add explicitly. However not having a test script would fail that command IIRC, so the addon basically has just a dummy script. Should we make the addon echo a different (less confusing) message, or just do a no-op? (I think the current message is useful, if you run test explicitly inside the addon folder. But less so, when run as part of the global test...)

Also, the current setup runs linting in CI twice, because it runs both yarn lint as a dedicated step, but also includes linting in the test-app's test script.

Hm, right. This merging of linting and tests comes from Ember's app blueprint. Not sure if that really makes so much sense, but it's nothing we can change easily, or at least would require overriding after the app blueprint ran. We could make the global test script call test:ember, but that would again work against this generalization concept of the global test delegating to each test of its workspaces mentioned above...

@NullVoxPopuli
Copy link
Collaborator

is this still an issue? and still an issue with yarn@3+?
(ie, can we casually drop / stop-caring about yarn@v1)

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

No branches or pull requests

3 participants