By using AWS re:Post, you agree to the Terms of Use
/AWS CodeArtifact/

Questions tagged with AWS CodeArtifact

Sort by most recent
  • 1
  • 90 / page

Browse through the questions and answers listed below or filter and sort to narrow down your results.

0
answers
0
votes
3
views
asked 2 months ago

[CodeArtifact] [Bug] Upstream repository for npm has different interpretation (breaking change) to "latest version" than https://registry.npmjs.org/

## Description of setup The web app my team is working on uses `yarn` as the node package manager with the registry hosted at a CodeArtifact registry. Our team's private npm packages are available on this registry. Our CodeArtifact registry is also configured to have an upstream repository. This upstream repository is connected to `https://registry.npmjs.org/`. ## Issue Our web app use multiple packages that have a dependency on `"@types/node": "*"` (see [here](https://www.npmjs.com/package/@types/node)). At the time of writing, these are the 5 latest versions sorted in order of their release date. 12.20.47 16.11.26 17.0.21 17.0.20 17.0.19 Given that the dependencies in our app have `@types/node: *` as a dependency, I would expect that doing `yarn install` installs the latest version. In the list above, that would be version `17.0.21`. However, when we are doing `yarn install` with the registry settings to the AWS CodeArtifact registry, we get the version `12.20.47`, which is the latest in terms of release date but not the latest in terms of semantic versioning. ## Proposal Can you look at fixing the issue with upstream repositories connected to the public npm registry so that the latest version is always the latest semantic version rather than the latest release date? ## Minimum replication Here is a minimal replication for the issue package.json ``` { "name": "demoBug", "version": "1.0.0", "description": "", "main": "index.js", "dependencies": { "ioredis": "4.28.1" }, "devDependencies": { "@types/node": "16.11.9", "@types/ioredis": "4.28.1" }, "author": "", "license": "ISC" } ``` Notice how `@types/ioredis` is the package that has a dependency on `@types/node: "*"`. .npmrc ``` registry="https://registry.yarnpkg.com" ``` .yarnrc ``` registry "https://registry.yarnpkg.com" ``` The result in the `yarn.lock` file is what is expected. yarn.lock (with integrity hash removed) ``` ... "@types/node@*": version "17.0.21" resolved "https://registry.yarnpkg.com/@types/node/-/node-17.0.21.tgz#864b987c0c68d07b4345845c3e63b75edd143644" "@types/node@16.11.9": version "16.11.9" resolved "https://registry.yarnpkg.com/@types/node/-/node-16.11.9.tgz#879be3ad7af29f4c1a5c433421bf99fab7047185" ... ``` See how the version of `@types/node` is at the latest semantic version (at time of writing) Now if we alter `.npmrc` and `.yarnrc` so that the default registry is an AWS CodeArtifact registry. .npmrc ``` registry="<URL to repository for in AWS CodeArtifact>" ``` .yarnrc ``` registry "<URL to repository for in AWS CodeArtifact>" ``` then this changes a change in `yarn.lock` when reinstalling npm packages (after removing any existing `yarn.lock` and `node_modules/` yarn.lock ``` "@types/node@*": version "12.20.47" resolved "https://registry.yarnpkg.com/@types/node/-/node-17.0.21.tgz#864b987c0c68d07b4345845c3e63b75edd143644" "@types/node@16.11.9": version "16.11.9" resolved "https://registry.yarnpkg.com/@types/node/-/node-16.11.9.tgz#879be3ad7af29f4c1a5c433421bf99fab7047185" ``` Notice the difference in versions for `@types/node`, even though the upstream repository in AWS is a mirror for the npm public registry.
0
answers
0
votes
4
views
asked 3 months ago

Publishing npm private package to AWS CodeArtifact (private field set to true in package.json)

# Context I am attempting to publish a *private* package to AWS CodeArtifact and having difficulties. The `package.json` file has its `private` field set to `false` to prevent accidental publishing to npmjs.com registry in case a developer in our team makes a mistake. Package publish to AWS CA fails with the expected error (see Response 1 below). Same thing happens when I specify the following `publishConfig` (see Response 2 below). ```json { "publishConfig": { "registry": "https://xxxxx-demo-domain-xxxxxxxxxxxx.d.codeartifact.us-east-1.amazonaws.com/npm/xxxxx-demo-repo/", "access": "restricted" } } ``` # Question How do I configure the `publishConfig` to allow the package to be published to a specific AWS CA domain/registry under our team control? I couldn't find information about it in the AWS Documentation nor on StackOverflow nor anywhere else online. ## Response 1 ```sh $ npm publish npm notice npm notice 📦 @ec/trivial-package@1.2.0 npm notice === Tarball Contents === npm notice 77B index.js npm notice 797B package.json npm notice === Tarball Details === npm notice name: @ec/trivial-package npm notice version: 1.2.0 npm notice filename: @ec/trivial-package-1.2.0.tgz npm notice package size: 541 B npm notice unpacked size: 874 B npm notice shasum: a356f71ca997c48c54cd91172884ae8da9911725 npm notice integrity: sha512-WSa7fmhfuSXFY[...]Nn9JqgAUaHSeA== npm notice total files: 2 npm notice npm ERR! code EPRIVATE npm ERR! This package has been marked as private npm ERR! Remove the 'private' field from the package.json to publish it. npm ERR! A complete log of this run can be found in: npm ERR! C:\Users\igors\AppData\Local\npm-cache\_logs\2022-01-06T01_47_28_986Z-debug.log ``` ## Response 2 ```sh $ npm publish npm notice npm notice 📦 @ec/trivial-package-2@1.0.0 npm notice === Tarball Contents === npm notice 77B index.js npm notice 609B package.json npm notice === Tarball Details === npm notice name: @ec/trivial-package-2 npm notice version: 1.0.0 npm notice filename: @ec/trivial-package-2-1.0.0.tgz npm notice package size: 507 B npm notice unpacked size: 686 B npm notice shasum: 57511cd858f92a1818621045f34bfd5723649271 npm notice integrity: sha512-uV5seBJT40fFy[...]BVD355OzLkcBQ== npm notice total files: 2 npm notice npm ERR! code EPRIVATE npm ERR! This package has been marked as private npm ERR! Remove the 'private' field from the package.json to publish it. npm ERR! A complete log of this run can be found in: npm ERR! C:\Users\igors\AppData\Local\npm-cache\_logs\2022-01-06T20_27_04_435Z-debug.log ```
0
answers
0
votes
4
views
asked 5 months ago
  • 1
  • 90 / page