Skip to content

Replace reinstall script with a simpler postinstall#55

Open
phillipj wants to merge 1 commit intoelm-community:masterfrom
phillipj:replace-reinstall-postinstall
Open

Replace reinstall script with a simpler postinstall#55
phillipj wants to merge 1 commit intoelm-community:masterfrom
phillipj:replace-reinstall-postinstall

Conversation

@phillipj
Copy link

Hi there,

first of all, thanks for a great starter pack 👍 Hopefully I'm not stepping on any toes here, just want to suggest some changes after prior experiences over the years.

These changes are suggested for a couple of reasons:

Ideally running npm install

npm install is the de-facto way of installing dependencies in npm projects.

The built-in install script has lifecycle scripts that allows us to perform actions after all npm dependencies has been installed for the project.

npm ensures that dependencies installed which includes executable files are available in $PATH when npm scripts are run. In practise that means a custom build npm script might use elm as if it were globally installed on the machine, but it infact is a devDependency to that particular project.

Avoiding global dependencies

Ideally a project does not require global packages installed on the machine to run. This is cause of two reasons basically:

  • There is no good way to specify a system wide dependency and its version
  • A developer might want to run different versions of e.g. elm on different projects. By enforcing global installs, that's quite painful.

Any thoughts? Are there reasons the previous reinstall existed that I'm overlooking?

These changes are made for a couple of reasons:

**Ideally running `npm install`**

`npm install` is the de-facto way of installing dependencies in npm projects.

The built-in install script has lifecycle scripts that allows us to perform
actions *after* all npm dependencies has been installed for the project.

npm ensures that dependencies installed which includes executable files
are available in `$PATH` when npm scripts are run. In practise that means
a custom `build` npm script might use `elm` as if it were globally installed
on the machine, but it infact is a `devDependency` to that particular project.

**Avoiding global dependencies**

Ideally a project does not require global packages installed on the machine
to run. This is cause of two reasons basically:

- There is no good way to specify a system wide `dependency` and its version
- A developer might want to run different versions of e.g. `elm` on different
  projects. By enforcing global installs, that's quite painful.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant