chore: add typescript-eslint package scaffold

[bradzacher]

PR Checklist

• Addresses an existing open issue: ESLint Flat Config Support #7694
• That issue was marked as accepting prs
• Steps in Contributing were taken

Overview

This PR just adds an private scaffold for the typescript-eslint package being added in #7935. I've split this out so that the automation will bump the versions with each release.

The most annoying part of the branch is every time I go back to it and rebase it on main I have to manually resolve and correct all of the versions or else things will use old releases from npm instead of the repo code.

[typescript-eslint]

Thanks for the PR, @bradzacher!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

---

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint.

[netlify]

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	7c3f8cc
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/65bb07b2c91994000866ab56
😎 Deploy Preview	https://deploy-preview-8296--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 90 (no change from production) Accessibility: 100 (no change from production) Best Practices: 92 (no change from production) SEO: 98 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[merceyz]

I have to manually resolve and correct all of the versions or else things will use old releases from npm instead of the repo code.

You can replace the explicit versions with workspace:*, Yarn will replace them on publish with the exact version.
https://yarnpkg.com/features/workspaces#cross-references

[bradzacher]

@merceyz oh that's interesting! I didn't know that existed.

I had noticed that there was the syntax when I looked at the lock file (you can see I used it in the root package.json) - but I didn't realise that it would automatically get replaced on publish! That's super cool!

Cc @JamesHenry - we use the nx packages for publishing - does nx use yarn npm publish under the hood or does it not? I.e. Could we use this syntax? Could nx support it?

And for an FYI @JoshuaKGoldberg

[JamesHenry]

@bradzacher Right now there is a fork in the road when it comes to non semver versions.

Either:

• you apply your versions using valid semver version in your source files, tracked by git

OR

• you can leverage either semver versions of any valid workspace/file protocol specifiers if version your dist files, not tracked by git

This second option is how the Nx repo itself does it. The source of truth for versions in this case is therefore not disk, but rather the npm registry. Nx release supports this case via config in nx.json.

---

Background

This fundamental choice is down to the implementation of nx release being based on isolated version/changelog/publish steps, and the fact that we want to publish something tangible on disk.

Some release tools read your files but then perform all kinds of modifications in memory which are not reflected anywhere on your file system for you to see/play with and then publish that in memory object to npm. This can make troubleshooting bad publishes nearly impossible at times - with this approach it's trivial, because you can always cd somewhere and run npm publish directly with whatever options you want.

So when you perform your versioning step, nx release gets your files ready for your publishing step on disk, therefore it needs to replace those workspace/file references with the real numbers so that they work for your consumers.

Now, having said all that...

When we first created this hard line we only had the three subcommands available: nx release version, nx release changelog, nx release publish and therefore was not straightforward way to plumb things through from one to the other.

These days we have the programmatic API for nx release as a first class use-case - it's already what we use in typescript-eslint, and so it is therefore possible for me to imagine exposing a util function on the programmatic API to reset workspaces/file references after running releasePublish. The main complication though will be not committing those package.json dependency updates as part of the versioning or changelog step. I think it is doable though.

This is the issue to track for progress: nrwl/nx#20978

[JoshuaKGoldberg]

LGTM to start, just requesting changes on the license and missing docs. 🚀

[JoshuaKGoldberg]

🚢

[JamesHenry]

Let’s finalize the discord discussion before merging

[JoshuaKGoldberg]

Update name as per discussion.