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.

Sign up for GitHub

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

Jump to bottom

Figure out the way to test different deps than the locked ones #39

Closed
stof opened this issue Jun 20, 2017 · 2 comments
Closed

Figure out the way to test different deps than the locked ones #39

stof opened this issue Jun 20, 2017 · 2 comments
Labels
HasPR

Comments

@stof
Copy link
Member

stof commented Jun 20, 2017 •
edited
Loading

As this package is used as a library by others, we have no guarantee that they will install dependencies being exactly the same than our locked deps.
So it would be great to have some CI job resolving deps separately from the lock.

We need to figure out what the Node.js best practices around that are, and apply them on our CI.
@stof stof mentioned this issue Jun 20, 2017
Closed
@steven-pribilinskiy steven-pribilinskiy mentioned this issue Nov 10, 2017
Closed
@steven-pribilinskiy
Copy link

steven-pribilinskiy commented Nov 10, 2017 •
edited
Loading

We could support npm and yarn by running both npm install and yarn add whenever a new package is added.
Unfortunately there's no guarantee that package-lock.json and yarn.lock will be equivalent. It's because some dependencies may commit package-lock.json and others yarn.lock

Unfortunately the package-lock.json file from NPM@5 is not supported by yarn
yarnpkg/yarn#3614

@stof
Copy link
Member Author

stof commented Nov 10, 2017 •
edited
Loading

@pribilinskiy I don't care about supporting both NPM and Yarn for people contributing to this project (people using this project are already free to use what they want).
This issue is about figuring out what the Node best practices are regarding versions of deps used on CI for libraries.
The lock file is a root-only thing anyway (like in composer).

@Lyrkan Lyrkan mentioned this issue Oct 7, 2018
Merged
@Lyrkan Lyrkan added the HasPR label Oct 7, 2018
weaverryan added a commit that referenced this issue Oct 18, 2018
@weaverryan
minor #403 Add new Travis jobs to test lowest/highest versions of all…
831adff 
… the dependencies (Lyrkan)

This PR was squashed before being merged into the master branch (closes #403).

Discussion
----------

Add new Travis jobs to test lowest/highest versions of all the dependencies

This PR adds two Travis jobs that allow to test the lowest and highest versions of all the dependencies (including the dev ones since the version ranges are used by the package helper).

I wasn't sure about the method to use for the lowest versions since we can't really guess them without calling the npm's registry API. So, if someone has a better idea... :)

Note that both jobs currently fail for the following reasons:

- Lowest versions: This isn't really an issue since it seems related to Webpack 4 for which we haven't released a version yet. We could increase the minimum version to match the one from the `yarn.lock` file before releasing.
- Highest versions: This is caused by the last version of the `mini-css-extract-plugin` (0.4.3) which doesn't seem to work well with the `webpack-manifest-plugin` anymore (see webpack-contrib/mini-css-extract-plugin#177 (comment)).

Closes #39.

Commits
-------

bcabda6 Add some missing 'return' statements
0161000 Remove hardcoded sass-loader version in addPackagesVersionConstraint test
7abea75 Add new Travis jobs to test lowest/highest versions of all the dependencies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
HasPR
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@stof @Lyrkan @steven-pribilinskiy