The CI failed? @antony

The CI failed? @antony

The CI can't possibly pass until https://github.com/sveltejs/eslint-config exists (i.e. is published to NPM)

@antony what do you think about going ahead and publishing @sveltejs/eslint-config? It seems a pretty safe starting point since it keeps things exactly as is. Then I can go ahead and update sveltejs/sapper#1198 to use it too

I'm happy to, but I don't have credentials. @Conduitry are you OK with this? Build config is in place, just needs NPM_TOKEN secret added to repo secrets, then it will publish on tag.

npm auth is something I'm a bit vague on. If I have 2FA enabled on my npm account, is there a way to generate a token that doesn't need a 2FA challenge to publish? And is there a way to generate a token that only permits publishing that one package?

They've got some instructions that mention 2FA: https://docs.npmjs.com/creating-and-viewing-authentication-tokens

Is there at least a way to create a token scoped to a particular org? Is my best bet to create a dummy user whose one ability is to be able to publish this package, and to create a token for it?

Alternatively, do we want to just not publish to npm at all, and install from Git tags wherever we use this? We don't expect other people to be using this - there's not really a convenience reason for it to even be on npm.

I'm not aware of anyway to scope tokens beyond their read/write permissions. I think the other project I work on went the dummy user route.

I've been installing Sapper via git url in my project and it's annoying because it has to run npm install, which takes a long time due to Cypress. I'm guessing npm install would be really fast on the eslint package though, so that's probably a fine way to go if it's just a couple projects using the package.

Yeah I don't see install time being a problem. The reason installing Sapper from Git takes so long is that its package.json has a prepare script, which means that npm also downloads all of its devdeps and runs npm run prepare in it (which runs npm run build) to get the built assets that aren't checked into the repo. But I can't imagine there'd have to be a build process with the ESLint config. It's probably pretty much just one CommonJS module exporting a configuration object.

Yeah, I just tested locally and it's pretty painless. One thing I still wonder though is if it will be harder to keep it up-to-date. Will npm-check-updates work in that scenario?

@Conduitry it's certainly an option yes - the only issue is that every time we added a rule we'd have to go and validate that the rule passed on every project, and update the ones which used it (which should eventually be all of them), otherwise the next person who makes a change is going to also have to lint the project according to the new rules. The rules will be in flux to begin with, so this will become a very arduous process.

I can imagine that opening a PR on ten projects for every new rule is going to hinder us considerably, to the point where we'd probably avoid doing it.

Having a versioned package which can be updated (turning rules to errors / adding new errors would be breaking) means that we can do this process as-and-when.

So I guess I have to vote no on this one.

We can still use git tags for versions, and npm has a feature that lets semver ranges work against git tags. https://docs.npmjs.com/cli/install (#semver:...) Because of lockfiles, we'd need to open PRs against every project anyway even if we were publishing to npm.

Ok. I'm willing to give this a go. I will update the PR shortly.

Ok - updated and installed as v0.0.1 from github, pending build passing, this should be ready to go with no further changes.