Some Ideas about kcd-scripts HOT 6 CLOSED

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!

from kcd-scripts.

@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?

from kcd-scripts.

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...

from kcd-scripts.

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?

from kcd-scripts.

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.

from kcd-scripts.

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.

from kcd-scripts.