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

Pin @types/node to 6.0.42 for yelb-ui #9

Merged
merged 1 commit into from
Sep 28, 2020
Merged

Pin @types/node to 6.0.42 for yelb-ui #9

merged 1 commit into from
Sep 28, 2020

Conversation

alexpulver
Copy link
Contributor

Latest versions of Node.js lead to the following exception when building yelb-ui Docker image:
node_modules/@types/node/index.d.ts(20,1): error TS1084: Invalid 'reference' directive syntax.

Pinning to 6.0.42 version (instead of ^) solves the issue.

Latest versions of Node.js lead to the following exception when building yelb-ui Docker image:
node_modules/@types/node/index.d.ts(20,1): error TS1084: Invalid 'reference' directive syntax.

Pinning to 6.0.42 version (instead of ^) solves the issue.
@mreferre
Copy link
Owner

Thanks Alex for opening the PR. In the past I have solved similar problems by elevating the node version of the container. I am no node expert but I'd rather try to solve it that way Vs pinning a library to a specific version. I need to do some research around this.

@alexpulver
Copy link
Contributor Author

In this case elevating Node.js version is exactly what caused the exception. The application code uses a reference directive syntax somewhere (I didn't capture the full exception, but it is easily reproducible). This directive is part of @typescript module, which is pinned to ~2.2.0 patch versions in package.json. My understanding is that this directive no longer recognized by latest Node.js version. Bumping @typescript module version breaks other parts of code, because it relies on the module interface, which significantly changed since 2.2.0.

Usually pinning is a best practice for reproducible builds (Why pin dependencies? provides a good explanation in my opinion). Explicit dependencies update provide a controlled path to testing first and upgrading later (e.g. Dependabot pull requests model).

@mreferre
Copy link
Owner

Oh absolutely. I don't disagree with you. I actually have this in the README as a bullet of the known issues & limitations section:

"While I am trying to explicitly declare container tags and modules versions moving forward, there is a chance that if you try > to build your own containers from the Dockerfile provided and/or install the project on a cloud instance, the output may be > diverging from one setup to another. Generic commands such as apt-get update, npm install and gem install sinatra may >lead to different versions of code and modules being pulled at build and setup times."

I just wanted this to be more pro-active than reactive like here (this is a message to self, not to you - thank you a ton for ringing the bell).

LGTM

@mreferre mreferre merged commit 069c132 into mreferre:master Sep 28, 2020
@alexpulver alexpulver deleted the patch-1 branch September 30, 2020 07:09
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.

2 participants