Some Ideas

[ozum]

Hi,

This is a not bug report. I want to thank you for the toolkit. Previously I used a toolkit similar to this idea from Walmart Labs (don't remember name), but kcd-scripts is more feature rich.

I implemented a derived version of kcd-scripts and would like to share a few ideas back here, hoping they are useful for others and hear what they think about them. My derivation is for typescript, but ideas are general.

• init script: Since there are tons of config files, this script generates necessary files in project directory, and creates script entries in package.json. For example:
  • Files such as .gitattributes, .gitignore, .prettierrc.js are generated.
  • build, test, validate etc. scripts entries are created.
  • Files which cannot inherit from another file, such as .gitattributes, is created as symlink to some base file in kcd-scripts. So whenever original file is updated, this files acts as updated as well.
  • Also typescript configuration must be in root folder of project, so it is also generated as symlink.
  • Some files are not needed to be in project folder to kcd-scripts work. However, IDEs are expecting them in project folder to be functional. For example WebStorm looks for .eslintrc, tsconfig.json etc. Those files are generated as inheriting from originals, so IDEs can find them, and they are up to date when kcd-scripts are updated.
  • Other related files mentioned below ideas are also generated.
  • init script is automatically executed via scripts.install entry in package.json, when the module is installed.
• Added TypeScript related scripts.
• Added TSLint scripts.
• Moved scripts.precommit entry to .huskyrc.js file, because it will be deprecated in next version of `husky``
• Added jsdoc2md script and readme.hbs template with doctoc support, which generates API docs both for JavaScript and TypeScript.

I didn't publish it yet, because it is still rough.

@kentcdodds, as the creator of original toolkit and experienced user of it, I would like to hear what do you think about those. Are there any caveats/pitfalls or any suggestions?

Kind Regards,

[kentcdodds]

Hey @ozum! Thanks for the feedback!

I love the idea of an init script. I currently use https://github.com/kentcdodds/generator-kcd-oss to scaffold out my projects. I think an init script would be cool, though I'd be a little concerned about the number of dependencies that would require which would only be used by the initialization step but you'd have to download them all forever thereafter. Currently for me, when I want to make a new project I just do:

npx -p yo -p generator-kcd-oss -c 'yo kcd-oss'

Which I have aliased to kcd-oss. So I'm thinking I wont do the init script...

The TypeScript thing is fine, but I wont include that in kcd-scripts. If I do any static typing support eventually it'll be with flow which wont really require any changes anyway.

I'll definitely eventually upgrade husky, but I'll probably using the package.json config instead.

In paypal-scripts, I switched to a remark plugin and I much prefer that so I'll probably switch this to that eventually.

Thanks for the feedback and ideas! Good luck on your fork!

[ozum]

@kentcdodds thanks for the feedback.

For init script; I think users of toolkit already pay dependency tax during npm install. I published my fork as moe-scripts. It is super specific to my needs, but you may want to give init script a try by installing it with npm install moe-scripts. If it didn't find types entry in package.json, it initializes for babel 7 and eslint.

My biggest concern is about symlinks. What do you think about using symbolic links?

[kentcdodds]

I'm not sure I understand, so you're saying that it conditionally installs packages based on the way the project is set up?

My biggest concern is about symlinks. What do you think about using symbolic links?

I'm not sure what you mean...

[ozum]

so you're saying that it conditionally installs packages based on the way the project is set up?

No, it installs all. Heavy, but in my case it is OK, because I use babel and tsc at the same project. However init initializes based on project type: moe-scripts compile uses babel or tsc according to project type.

"name": "Dummy Project",
"types": "lib/index.d.ts"

For above, npx moe-scripts init creates tslint.json, tsconfig.json etc. moe-scripts build uses tsc

"name": "Dummy Project",

For above, npx moe-scripts init creates Babel related files. moe-scripts build uses babel

I'm not sure what you mean...

I use symbolic links for .gitignore, .gitattributes etc. instead of creating real files. For example my-project/.gitignore points to my-project/node_modules/moe-scripts/dist/config/gitignore/compile file.

So, after I update config file in moe-scripts and whenever project uses new version of moe-scripts it uses updated .gitignore configuration.

Please see a sample project root for an example: (Auto executes moe-scripts init after install)
mkdir dummy-project && cd dummy-project && npm init -y && npm install -save-dev moe-scripts

Do you see any caveats on usage of symbolic links like that?

[ozum]

so you're saying that it conditionally installs packages based on the way the project is set up?

I didn't do it, but it seems possible. You can divide kcd-scripts into a few rough parts such as kcd-scripts-babel, kcd-scripts-rollup, kcd-scripts-flow.

Main module kcd-scripts installs common parts and after looking a config file or details in package.json of the project, it can further install additional related sub modules.

[kentcdodds]

One of the benefits of kcd-scripts is that you don't have to think about the underlying tools 90% of the time. If I were to extract everything that would sort of defeat the purpose.

That said the initial download is pretty big and I do want to reduce that. So I've been thinking about ways to lazily download some dependencies and I think I may have an idea. It will probably be a while before I implement it (lots of other priorities), but it basically amounts to caching the dependencies on-demand. So the first time you run a script it may take a moment to install some things, but the second time they'll be cached.

I'm not certain this will work, but we'll see. I'll let you know if I ever work on this.

As for symbolic links, I used to do that but I no longer do because it became too confusing and sometimes it didn't seem to work very well on other people's machines. So I don't mind duplicating things like those files. They don't change very often anyway.