Use NPMRC_DATA to write .npmrc file in auto-indexing job for Typescript

[keynmol]

This is to support a .npmrc location that can be populated from an executor secret, and we write it to a global location.

This seems to be the recommended way to authorise with JFrog artifactory hosting NPM packages.

https://jfrog.com/help/r/jfrog-artifactory-documentation/npm-registry

Documentation addition

Test plan

• Amended existing automated tests
• Manual testing

[sourcegraph-bot]

Codenotify: Notifying subscribers in CODENOTIFY files for diff a77a49f...3907752.

Notify	File(s)
@Strum355	enterprise/internal/codeintel/autoindexing/internal/inference/lang_typescript_test.go enterprise/internal/codeintel/autoindexing/internal/inference/lua/typescript.lua
@efritz	doc/code_navigation/how-to/configure_auto_indexing.md enterprise/internal/codeintel/autoindexing/internal/inference/lang_typescript_test.go enterprise/internal/codeintel/autoindexing/internal/inference/lua/typescript.lua

[michaellzc]

nice, but can we also document it somewhere in the docsite?

[keynmol]

nice, but can we also document it somewhere in the docsite?

ah yes, good point.

[varungandhi-src]

which should be recognised by tools like NPM and Yarn

Are you sure that Yarn supports this? Looking at the comments here: yarnpkg/yarn#871 as well as this SO answer: https://stackoverflow.com/a/72365311/2682729 -- Yarn seems to require a different .yarnrc file.

[keynmol]

Hm reading the PR you linked it falls back to .npmrc if it can't find its own file?

Also JFrog suggest that Yarn explicitly works: https://jfrog.com/help/r/jfrog-artifactory-documentation/using-yarn

The way I'm reading it is that you can use either, and Yarn obviously prefers its own thing, but it should support whatever is in .npmrc as well

[keynmol]

JFrog's docs suggest that auth information in .npmrc should work
The issue you mentioned suggests that the registry address itself only works from .yarnc

Looks a bit messy, but may be we should get this into the hands of customers and see if it works for them? If not can always add YARNRC_DATA for this.

[varungandhi-src]

Hm reading the PR you linked it falls back to .npmrc if it can't find its own file?

Right, but some commenters point out that it doesn't work, at least in some situations (e.g. this comment: yarnpkg/yarn#871 (comment)). I can't figure out the details though, whether it's "just" user error or not...

JFrog's docs suggest that auth information in .npmrc should work

Could you add a link to the docs in the Lua code where the .npmrc is being written, indicating that it is meant to work for Yarn too?

Looks a bit messy, but may be we should get this into the hands of customers and see if it works for them? If not can always add YARNRC_DATA for this.

It seems like the data is the same, the only difference is the format, right? So would it make sense to unconditionally write the .yarnrc file too, just in case?

Also, in terms of a feedback loop, I think it will not be fun to debug if a customer runs into this... If we'd like to merge this soon because of code freeze, I'm OK with merging this...

FWIW, in the past, I've used the free Artifactory trial to actually test out this kind of situation. It's pretty cumbersome, but it gave greater confidence in things working as expected. And as cumbersome as it was, it was still faster than iterating with a customer.

[keynmol]

It seems like the data is the same, the only difference is the format, right? So would it make sense to unconditionally write the .yarnrc file too, just in case?

Ah, I see what you mean now.

Took a look at the docs for Yarn itself - seems like we can't get away with same data:

Starting from the v2, they must be written in valid Yaml and have the right extension (simply calling your file .yarnrc won't do).

I will amend the docs to only mention npm, and address Yarn separately (there's an issue with Executors UI I need to fix beforehand)