Integrate liferay-npm-scripts into Liferay Learn #91
Comments
|
@jrhoun, feel free to chime in! |
|
Thanks @rdai10. I added one comment here:
For example, I don't think it's Prettier which is throwing the error you're talking about here:
It's probably coming from ESLint. Can you share the console output so that we can analyze it and confirm that hypothesis? If it is from ESLint, we don't need/want to use
You can't really do any So, if you want to selectively format some of The other thing I think we'll need to do is teach the scripts to accept |
|
@wincent The project has been adjusted to using I looked around, lots of people seem to be wanting a jinja plugin for prettier but nobody has written it yet. The closest I found was https://github.com/robertquitt/prettier-plugin-djangohtml but alas it is not a working version. |
|
The other thing you can do if you want to turn ESLint back on is tell it that Something like this in an module.exports = {
globals: {
$: true,
},
};If you don't want to force usage of arrow functions, you can add this too: rules: {
'prefer-arrow-callback': 'off',
},(The reason we prefer arrows in liferay-portal is we have Babel running over everything, which means arrow functions get safely transpiled and don't break IE.) |
|
Thanks @wincent ! I added the config at https://github.com/brianchandotcom/liferay-learn/pull/74 and everything works as expected. |
|
So we just pushed @liferay/npm-scripts v33.1.0, which includes that PR #103 allowing it to format YAML and Markdown. At this point, @rdai10, we can probably close this issue. The remaining wish-list item (formatting those Jinja2 templates which have ".html" extension) could be split into another issue — although given the cost (high) vs the relative reward (🤷♂️), it would probably not be something that we would be likely to prioritize in the short-term. |
|
Hey @wincent github action also throws the same error: Looks like there's unmet dependency? |
|
Cool, thanks for reporting that. We use |
This isn't _strictly_ necessary, but it is an accurate description of the requirements of the project. We go with the range of "^3.6.3" to match the lowest range that we're currently using in any project (which is found in liferay-js-toolkit), to minimize the risk of introducing duplicates in a consuming project. If you have a ".ts" file in your project, you are going to have `typescript` in your `devDependencies`, and our `overrides` configuration is going to use `@typescript-eslint/parser`, which in turn is going to require `typescript`, transitively, in `@typescript-eslint/typescript-estree` here: https://github.com/typescript-eslint/typescript-eslint/blob/c5ffe8833da7875e82953de117b0abe6fa8a60b0/packages/typescript-estree/src/parser.ts#L2 And all will work, even though `@typescript-eslint/typescript-estree` doesn't explicitly declare its hard dependency on `typescript` in its package.json: https://github.com/typescript-eslint/typescript-eslint/blob/c5ffe8833da7875e82953de117b0abe6fa8a60b0/packages/typescript-estree/package.json#L41-L49 But if you don't have any ".ts", then you shouldn't need to have `typescript` in your dependency graph, and we won't use `@typescript/eslint-parser`. So, it makes sense for us to call this an `peerDependency` and mark it as `optional` as per these posts: - https://medium.com/@noamgjacobsonknzi/what-is-peerdependenciesmeta-acea887c32dd - npm/cli#1247 (Note that the `peerDependenciesMeta` field isn't documented yet.) You could also argue that this should be under `optionalDependencies`: https://docs.npmjs.com/files/package.json#optionaldependencies But I think "optional peer" comes closer to the reality here. `optionalDependencies` is for things that you can add, but the package should work if they're not there. That's not the case here. The package won't work if you have ".ts" files but no `typescript`. Related: #91 (comment)
This isn't _strictly_ necessary, but it is an accurate description of the requirements of the project. We go with the somewhat unsatisfying range of "*" to to minimize the risk of introducing duplicates in a consuming project. At the moment, we're using v4+ in this monorepo, 3.9.7 in liferay-portal, and the lowest range that we're currently using in any other project is "^3.6.3" (in liferay-js-toolkit). In the future, we should be able to converge on v4+. If you have a ".ts" file in your project, you are going to have `typescript` in your `devDependencies`, and our `overrides` configuration is going to use `@typescript-eslint/parser`, which in turn is going to require `typescript`, transitively, in `@typescript-eslint/typescript-estree` here: https://github.com/typescript-eslint/typescript-eslint/blob/c5ffe8833da7875e82953de117b0abe6fa8a60b0/packages/typescript-estree/src/parser.ts#L2 And all will work, even though `@typescript-eslint/typescript-estree` doesn't explicitly declare its hard dependency on `typescript` in its package.json: https://github.com/typescript-eslint/typescript-eslint/blob/c5ffe8833da7875e82953de117b0abe6fa8a60b0/packages/typescript-estree/package.json#L41-L49 But if you don't have any ".ts", then you shouldn't need to have `typescript` in your dependency graph, and we won't use `@typescript/eslint-parser`. So, it makes sense for us to call this an `peerDependency` and mark it as `optional` as per these posts: - https://medium.com/@noamgjacobsonknzi/what-is-peerdependenciesmeta-acea887c32dd - npm/cli#1247 (Note that the `peerDependenciesMeta` field isn't documented yet.) You could also argue that this should be under `optionalDependencies`: https://docs.npmjs.com/files/package.json#optionaldependencies But I think "optional peer" comes closer to the reality here. `optionalDependencies` is for things that you can add, but the package should work if they're not there. That's not the case here. The package won't work if you have ".ts" files but no `typescript`. Related: #91 (comment)
As reported here:
#91 (comment)
Our use of the `@typescript-eslint/parser` (since 50a4d99) means
that we have a runtime dependency on `typescript` package. This worked
fine in liferay-portal, where `typescript` is already present, but not
in liferay-learn, where it is not. And I didn't know that
`@typescript-eslint/parser` doesn't actually declare all of its
transitive dependencies; as noted in:
#113
`@typescript-eslint/typescript-estree` does an unguarded `import` of
`typescript` even though it is not declared in its dependencies (they
declare it as an optional peer dependency).
So, let's not only fix this, by explicitly declaring our dependency on
TypeScript, but also declare all of our TS-related dependencies. This
will allow us to delete the devDependencies currently declared here:
https://github.com/liferay/liferay-portal/blob/f1a2b2ce06fa050d5e1ab193728ab9ec06df4315/modules/apps/remote-app/remote-app-client-js/package.json#L3-L6
As reported here:
#91 (comment)
Our use of the `@typescript-eslint/parser` (since 50a4d99) means
that we have a runtime dependency on `typescript` package. This worked
fine in liferay-portal, where `typescript` is already present, but not
in liferay-learn, where it is not. And I didn't know that
`@typescript-eslint/parser` doesn't actually declare all of its
transitive dependencies; as noted in:
#113
`@typescript-eslint/typescript-estree` does an unguarded `import` of
`typescript` even though it is not declared in its dependencies (they
declare it as an optional peer dependency).
So, let's not only fix this, by explicitly declaring our dependency on
TypeScript, but also declare all of our TS-related dependencies. This
will allow us to delete the devDependencies currently declared here:
https://github.com/liferay/liferay-portal/blob/f1a2b2ce06fa050d5e1ab193728ab9ec06df4315/modules/apps/remote-app/remote-app-client-js/package.json#L3-L6
|
We just pushed https://github.com/liferay/liferay-frontend-projects/releases/tag/npm-scripts%2Fv33.1.2 which should include the necessary |
|
Thanks @wincent for all your help! Applied the changes at https://github.com/jrhoun/liferay-learn/pull/701 and all seems to be working! |
|
Cool. Thanks for confirming @rdai10. |
The Liferay Learn project would like to use
@liferay/npm-scriptsto format its source code (scss,js,md,yml, and html in the form ofjinja 2templates).Preliminary work has been done to incorporate the package into the Learn project, but it's only being used to format
scssso far. There are a few bumps on the road:Sphinxthat packages jquery out of the box. In the project's javascript files, there are references to the jquery$that throws errors when using npm-scripts. Are there any tips for configurations that we can add to get around that? A way to avoid inlining<!-- prettier-ignore -->comments would be preferred./docsand/sitefolders at the root to create a separation between documentation material and its website source. However, we do want to be able to format all the md files in the/docsfolder from inside the/site/homepagefolder. I ran into issues defining an appropriate glob pattern to go up the directories for mynpmscripts.config.jsfile. I came across feat: handling globbing internally for Prettier liferay-npm-tools#141 where a custom glob library was implemented forliferay-npm-scriptsand hope to receive some help understanding what it expects.Let me know if I can provide any clarification that will be helpful! Thanks!
The text was updated successfully, but these errors were encountered: