anseki / plain-draggable

The simple and high performance library to allow HTML/SVG element to be dragged.
https://anseki.github.io/plain-draggable/
MIT License
773 stars 99 forks source link

npm does not install required dependencies #3

Closed caghand closed 6 years ago

caghand commented 6 years ago

Hi anseki,

When someone installs the plain-draggable package using npm (or yarn), the required dependencies are not installed automatically: anim-event cssprefix m-class-list etc.

People who are using their own module bundler can't use your minified bundle. They need to import the non-minified version. And in that case, the packages above are needed during run time, so they should be included as "dependencies" and not as "devDependencies" in your package.json.

"devDependencies" are reserved for dependencies that are only needed during the development life-cycle of plain-draggable (e.g. "webpack").

After you sort out "dependencies" and "devDependencies" in this way, users will be able to import your package much more smoothly.

This problem exists in leader-line as well.

Thanks!

-Caghan

anseki commented 6 years ago

The packages should be specified as devDependencies not dependencies because those are already bundled. Typically, bundled packages are specified in devDependencies to avoid installing those for users that do npm install PACKAGE. They don't need bundled packages. Only developers need those. Also, they install those (devDependencies) by npm install. Remember, devDependencies means "develop".

anseki commented 6 years ago

If you want to import PlainDraggable to your app, note that there is a required task other than installing sub packages. webpack.config.rules.js is provided for developers who import it via Webpack. See PlainModal that uses PlainDraggable.

caghand commented 6 years ago

You are right that "dependencies" entries are not needed if they are already bundled. But, as more and more users start consuming "jsnext:main" instead of "main", they will access your non-bundled (ES2015) version, and in that case, they will expect the dependencies to be installed & discovered automatically.

Personally, I think it's OK that your "main" script is a bundle that includes dependent packages. But then I would expect your "jsnext:main" script to be a bundle as well. Or, alternatively, I would expect that your dependencies are declared correctly, so that npm installs them automatically, and bundlers that consume "jsnext:main" can find them. :)

-Caghan

anseki commented 6 years ago

Hi @caghand,

I think that the user who needs jsnext:main/module script is developing something. Therefore, he/she should install packages via devDependencies. In other words, both jsnext:main/module and devDependencies are specified for developers.

I assent to your thinking that trouble might occur because the devDependencies packages are not installed automatically. As far as I know, only npm install command in each parent package installs the devDependencies packages. However, that is an issue about NPM. I think that, for the time being, in accordance with the custom, we should specify those packages as devDependencies. Then, unfortunately we can do nothing until NPM supports new function to install devDependencies packages automatically but I think that it is not big problem because the user who needs jsnext:main/module script may know that he/she should do npm install command. How do you think?

caghand commented 6 years ago

Hi @anseki,

Well... Your understanding of the meaning of devDependencies seems to be incorrect. The "dev" in devDependencies refers to the developer of that particular package. In plain-draggable, this would be you (anseki), not me.

When I create a Node project, yes, I am the developer of that project. In my project, I install & consume hundreds of npm packages. I am not developing those packages. So I don't want to install their devDependencies. Their devDependencies are things like their transpilers, test frameworks, documentation frameworks, bundlers, etc., which I don't need. However, I need every dependency that is required for me to consume (bundle & run) those packages. To ensure this, npm automatically installs the dependencies of those packages. This is how Node projects work, and it's not a bug; it is intentional. :) That is how people expect it to work.

This meaning of devDependencies is not my personal interpretation; it's the general understanding: https://stackoverflow.com/questions/18875674/

If we didn't have these guidelines, then project developers would need to run npm install for every one of their consumed packages (hundreds of times) in order to get their projects to build successfully. And, because of this action, they would be installing thousands of unnecessary devDependencies (transpilers, test frameworks, documentation frameworks, bundlers, etc.).

-Caghan

anseki commented 6 years ago

Sorry, my English is very poor, and I couldn't explain well... Of course I understand the devDependencies meaning as you said. For example, you will see that the devDependencies and dependencies are used correctly if you see my other Node projects. I meant that the user who imports file via jsnext:main/module needs devDependencies packages. However, web app project and Node project are a little different. That is, ES5 in web browser doesn't support module system, and bundler is used for that. The bundled file was already solved dependencies packages. Therefore, those unneeded packages should be specified as devDependencies for bundled file.

caghand commented 6 years ago

Oh, sorry about the misunderstanding. But now I think I understand your arguments.

I have now understood that your primary, first-class audience is users who make a <script> tag from the main property. Users who are "module importers" are not your primary audience; they have lower priority.

Of course, you don't want your primary audience to download unnecessary dependencies, so you don't declare those dependencies. The disadvantage is that "module importing users" need to take some manual steps to install those dependencies. You can't make everyone happy, and you have to make a choice between these two groups of people, so the primary audience wins. :)

Maybe, one day, "module importing users" will be your primary audience, and you will leave the responsibility of bundling to your consumers, instead of doing it yourself. Until then, we can close this issue.

Thanks!

-Caghan

anseki commented 6 years ago

I want to support both legacy tools and modern tools (i.e. "module importing users"). I don't think that the modern tools have lower priority but the legacy tools need more help because they have options less than the modern tools. That is, the bundled file is required for legacy tools. Also, installing devDependencies packages is not impossible. Therefore, I specified those packages as devDependencies.

Thank you for your comment. :smile:

mikila85 commented 4 years ago

so for us "module importers"... how to import? :( nothing works..

doing: import PlainDraggable from 'plain-draggable'; gives: ERROR - UncaughtException: plain_draggable_1.default is not a constructor

@anseki Please help :)

mikila85 commented 4 years ago

if someone encounters this and want to use import.. Draggabilly just works out of the box and has mostly same functionality. use: import * as Draggabilly from 'draggabilly';

anseki commented 4 years ago

Hi @mikila85, thank you for the comment and your solution. That might help someone. :smile: