yarn run publish
yarn run v1.7.0
$ monorepo-utils-publish
? Do you publish these packages?
@monorepo-utils/collect-changelog <= HERE
Yes
✓ @monorepo-utils/[email protected]
Publish successful!
✨ Done in 13.44s.
Thanks for making this tool! I think some users may want to also add the references to the root tsconfig.json file. In that way, they can run tsc --build from the root directory to build all referenced packages.
/Users/oliveryasuna/.nvm/versions/node/v16.16.0/bin/node /Users/oliveryasuna/.nvm/versions/node/v16.16.0/lib/node_modules/yarn/bin/yarn.js run update-references
/Users/oliveryasuna/Dropbox/NEWNEW/Personal/Programming/Projects/panama/.yarn/cache/@monorepo-utils-workspaces-to-typescript-project-references-npm-2.8.2-ed34f206b0-749ab95089.zip/node_modules/@monorepo-utils/workspaces-to-typescript-project-references/lib/index.js:56
throw new Error("Not found supported plugin");
^
Error: Not found supported plugin
at Object.toProjectReferences (/Users/oliveryasuna/Dropbox/NEWNEW/Personal/Programming/Projects/panama/.yarn/cache/@monorepo-utils-workspaces-to-typescript-project-references-npm-2.8.2-ed34f206b0-749ab95089.zip/node_modules/@monorepo-utils/workspaces-to-typescript-project-references/lib/index.js:56:15)
at Object.<anonymous> (/Users/oliveryasuna/Dropbox/NEWNEW/Personal/Programming/Projects/panama/scripts/updateReferences.js:24:45)
at Module._compile (node:internal/modules/cjs/loader:1105:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
at Object.require$$0.Module._extensions..js (/Users/oliveryasuna/Dropbox/NEWNEW/Personal/Programming/Projects/panama/.pnp.cjs:9955:33)
at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.require$$0.Module._load (/Users/oliveryasuna/Dropbox/NEWNEW/Personal/Programming/Projects/panama/.pnp.cjs:9778:22)
at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:170:29)
at ModuleJob.run (node:internal/modules/esm/module_job:198:25)
at async Promise.all (index 0)
We use --tsconfigPath src/tsconfig.json to target the correct tsconfig.json file, as this is where we want the references, but we want the references for example for package b to be like:
{
"references": [
{
"path": "../../a/src"
}
]
}
Instead of:
{
"references": [
{
"path": "../../a"
}
]
}
Solution
Would it be safe to assume that the directory structure given in --tsconfigPath can be used for referenced projects?
I will make a PR for this on my fork and see how it goes - let me know what you think about this solution. I guess the alternative is to add another CLI option for it.
lerna WARN notice Package failed to publish: @monorepo-utils/package-utils
lerna ERR! E404 Not found
lerna ERR! errno "undefined" is not a valid exit code - exiting with code 1
Error: Process completed with exit code 1.
When using workspaces-to-typescript-project-references --tsconfigPath tsconfig.prod.json --includesRoot
The workspace tsconfig.prod.json reference paths include the custom tsconfigPath "references": [ { "path": foo/bar/tsconfig.prod.json" } ]
but the root tsconfig.prod.json reference paths do not "references: [ { "path": "foo/bar" }]
It'd be great if the tool used the tsconfigPath for the reference paths in the root too, or if there was an option to enable this.
I like the the new version command in lerna 3.0. I also like the lean monorepo approach (aka golden path) based on file specifiers that is demonstrated in zillow/javascript and lerna/lerna.
However, it is still not clear how to achieve the release flow that your script facilitates -- without using some script such as yours. In particular, I want the dev to bump the version in their branch, and have CI publish the changes once they are merged to master.
One of the features of lerna is that it changes file-specifiers in package.json to version numbers before publication. I don't think your script does that now.
Using TS project references, if I build a package, it will build its dependencies in the same monorepo if there were no changes since the last build.
It does this by comparing the oldest modified timestamp under dist/ to the newest under src/. It does not care if the contents of the files are the same.
This presents a problem if using workspaces-to-project-references on a pre-commit hook, as we do, as tsconfig.json will always be "touched" on every commit. This means that the typescript compiler will always think that src is ahead of dist, even if there were no changes
Solution
Only write the file if the contents will be different.
I will chuck up a PR shortly
Some of our packages aren't typescript and just plain js. But they get inserted as references anyway. It should check if there's a tsconfig before adding.
The project reference for package-b is omitted from package-a as the version does not match.
Actual behaviour
The project reference for project-b is written into project-a regardless. When using Yarn Workspaces (and probably others), even though TS will have built the project reference, importing it actually uses the older version from node_modules/, so building is pointless.
Suggestion
When filtering the project references of project-a, check the package.json for both projects and ensure the version of project-b matches what is in project-a's package.json
The path property of each reference in a TypeScript project can point to a directory containing a tsconfig.json file or directly to the config file itself (which may have any name).
The path property of each reference can point to a directory containing a tsconfig.json file, or to the config file itself (which may have any name).
-- TypeScript Handbook
I am reporting an issue where workspaces-to-typescript-project-references does not work as expected in this context.
Therefore, running tsc -b in the a package should compile both tsconfig.json and the referenced tsconfig.types.json, emitting files to the lib and types directories, respectively.
While specifying the config file in the path property may not be common, tools like moonrepo consider this approach as a valid use case, as described here.
For the entire monorepo, the relationship between the config files is as follows:
Hi guys, I was wondering if it wouldn't be that complicated to add an option to sort references using a dependent-upon logic instead of an alphabetical one (especially in the root tsconfig file).
By dependent-upon logic I mean for packages that are dependencies for other packages to appear first in the lists.
I assume you already have the required information since you need to resolve the dependency graph to create the references.
I know that it is some sort of edge case, but I think that this sorting logic could be of more value than the alphabetical one (which can be easily obtained at a latter time).
My intention is to import my tsconfig file and use the references list. This way I don't need to keep a separate list of dependencies with this particular order elsewhere.
if a semver range, it will select the workspace matching the specified version.
If a module has a non-compatible dependency with the rest of the monorepo, yarn 1 will resolve this inside a node_modules folder inside the module folder - but only for this module. Whereas the current logic will use this to resolve dependencies for other modules
I recommend avoiding re-implementing the dependency resolution logic in this library and instead re-using the resolution logic of the build tool chosen by the plugin
it will work, however the path that gets written will point to ../../my-package/src, where really I need it to be ../../my-packages/src/tsconfig-esm.json.
Potential solution
Use the filename provided in --tsconfigPath, in this case tsconfig-esm.json and append this to the path only if it is not tsconfig.json (the default).
This makes the assumption that the same filename would be used in the referenced projects. This similar assumption was made as part of #39, where we assume that if the --tsconfigPath is src/tsconfig.json, then all referenced paths should also have src on the end, so I think this is a fine assumption to make.
Unfortunately, I've faced the issue with the workspaces-to-typescript-project-references on Windows machine:
PS D:\dev\repos\devops\yaft> npm run lint
> [email protected] lint D:\dev\repos\devops\yaft
> npm run ts:references:check && npm run lint:dependecies && npm run lint:es && npm run lint:prettier
> [email protected] ts:references:check D:\dev\repos\devops\yaft
> workspaces-to-typescript-project-references --check
Error: Not found supported plugin
at Object.exports.toProjectReferences (D:\dev\repos\devops\yaft\node_modules\@monorepo-utils\workspaces-to-typescript-project-references\lib\index.js:20:15)
at D:\dev\repos\devops\yaft\node_modules\@monorepo-utils\workspaces-to-typescript-project-references\lib\cli.js:77:28
at Generator.next (<anonymous>)
at D:\dev\repos\devops\yaft\node_modules\@monorepo-utils\workspaces-to-typescript-project-references\lib\cli.js:8:71
at new Promise (<anonymous>)
at __awaiter (D:\dev\repos\devops\yaft\node_modules\@monorepo-utils\workspaces-to-typescript-project-references\lib\cli.js:4:12)
at Object.exports.run (D:\dev\repos\devops\yaft\node_modules\@monorepo-utils\workspaces-to-typescript-project-references\lib\cli.js:64:74)
at Object.<anonymous> (D:\dev\repos\devops\yaft\node_modules\@monorepo-utils\workspaces-to-typescript-project-references\bin\cmd.js:3:6)
at Module._compile (internal/modules/cjs/loader.js:1138:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
Note that glob patterns can only contain forward-slashes, not backward-slashes, so if you want to construct a glob pattern from path components, you need to use path.posix.join() instead of path.join().
Seems that the simplest fix is to use upath instead of path.
I can send a PR with these changes if you don't mind.
I can fix this manually but workspaces-to-typescript-project-references will revert back to the more verbose formatting with every update so it is a bit tedious. I tried using prettier to auto-format it but prettier will respect multi-line json objects and keep them as-is.