The recent iteration to move @lauf w. pnpm to @watchable w. npm has been a failure, triggered by a cascade of build problems arising from npm not respecting the publishConfig main field.

In a pnpm context, the module can provide direct resolution of Typescript source files by having "main":"./src/index.ts" while ALSO publishing with "main":"./dist/index.js" during the prepublish (bundle) pack and publish process as a supported feature pnpm publish. By contrast npm ignores the intent to overwrite the "main" field of package.json.

This is crucially what allowed all local resolved paths to be fulfilled by "main":"./src/index.ts" within the repo. While trying to lean into the npm way of doing things, there was a tooling explosion required to watch and ensure that index.js was maintained transpiled and up-to-date with all upstream .ts sources. There is no good way to correctly address several issues arising from this. This is a very fragile setup.

Related, debugging depends on sourcemaps which are very flawed right now, all of which goes away if you reference the source directly and let the target bundler do the work (e.g. a Vite web app project which is a peer apps package in the repo can just straight-up resolve the Typescript source, so it gets the bundling and sourcemapping right.

Prospects

There are prospects for keeping the standardisation on npm. Potentially allowing "main" to be "src/index.ts" and the exports fields providing IIFE, CommonJS and ESM versions pointing to js, mjs, cjs. This would mean that the local environment (Typescript) can resolve source correctly via main, yet when the module is distributed bundlers can access various other preferred forms.

An alternative might be to point to the actual source in the "types" field? More detail of the use of exports in https://devblogs.microsoft.com/typescript/announcing-typescript-4-7/#package-json-exports-imports-and-self-referencing

It's maybe possible to be 'agnostic' regarding the eventual resolution to allow the two procedures to resolve differently. For example if you resolve to "./src" this may resolve to "./src/index.ts" when that file is present and in the scope of a Typescript compilation task, while the same specification can resolve to "./src/index.js" when that file is present and in the scope of a javascript task.

This means unfortunately that there will be a .js alongside a .ts during some stage. Perhaps just "src/index.js" can actually exist, and can simply import "./dist/index.js", with then the whole of the typescript source living in ./src (with only a permanent index.js import alongside the top index.ts - no other .js files generated ).

cefn / watchable

Re-bundle to allow src/index.ts to be locally resolved #5

Prospects