Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

foxy should respect env variable COMPOSER for finding packages.json #5

Closed
schmunk42 opened this issue Sep 12, 2017 · 10 comments
Closed
Labels

Comments

@schmunk42
Copy link
Contributor

Related to #3 (comment)

Besides that, it would be nice to have to possibility to define a custom packages.json file/path.

@francoispluchino francoispluchino self-assigned this Sep 12, 2017
@francoispluchino francoispluchino added this to the 1.0.0 milestone Sep 12, 2017
@francoispluchino
Copy link
Member

So, the priority to define the directory of the package.json file:

  1. The env COMPOSER with dirname() function
  2. The option --working-dir
  3. The getcwd() function

Currently, only 2 and 3 are available.

@francoispluchino
Copy link
Member

For your example:

/app/composer/composer.json
/app/composer/composer.lock
/app/composer/packages.json
/app/src
/app/vendor

With your proposal, the node_modules will live in app/composer/node_modules and not int app/node_modules.

NPM and Yarn can change the installation directory:

$ npm install --prefix <path>
$ yarn install --modules-folder <path>

To determine the base directory, I check the same base of the env COMPOSER directory and the vendor directory?

@francoispluchino
Copy link
Member

If I use the env COMPOSER to defined the working directory for the asset manager (so for your example /app/composer), and you do not want to install the assets in the directory app/composer/node_modules, but in app/node_modules, you can override the manager options in your composer.json file (with the currently implementation):

{
    "config": {
        "foxy": {
            "manager": "yarn",
            "manager-install-options": "--module-folder /app/node_modules",
            "manager-update-options": "--module-folder /app/node_modules"
        }
    }
}

Is this sufficient? Or do you want an automatic research of the common base of directories between composer vendor directory and the composer file?

@francoispluchino
Copy link
Member

I have just read the documentation of NPM, and it is indicated that a package is a folder containing a program described by a package.json file., In addition, the command npm install --prefix <path> does not behave as expected with NPM v5.4 (see this issue and this one).

So, if I respect the env COMPOSER, the package.json file will be in the same directory as the composer.json file, as well as the node_modules folder, and I should change the working directory specially for NPM/Yarn. I do not think that is the expected behavior.

Foxy should not be required to use NPM or Yarn. Each developer must be able to use all native features and commands of NPM or Yarn independently of Composer. That's Foxy's goal.

To conclude, I think it's a false good idea to uses the env COMPOSER, and that it is preferable to use the working directory of Composer, and it's is already the case. However, I am always open to discuss in the event you have a native solution to NPM and Yarn to do your configuration.

@schmunk42
Copy link
Contributor Author

To determine the base directory, I check the same base of the env COMPOSER directory and the vendor directory?

Yes.

Is this sufficient? Or do you want an automatic research of the common base of directories between composer vendor directory and the composer file?

I think that's fine. I'd rather even think about not splitting update and install options. So you could have common options for both.

So, if I respect the env COMPOSER, the package.json file will be in the same directory as the composer.json file, as well as the node_modules folder, and I should change the working directory specially for NPM/Yarn. I do not think that is the expected behavior.

That's also true. node_modules should not go into /app/composer - that would make no sense. In my case I'd need to reconfigure it to have node_module beside vendor.

Foxy should not be required to use NPM or Yarn. Each developer must be able to use all native features and commands of NPM or Yarn independently of Composer. That's Foxy's goal.

💯 % agreed!

To conclude, I think it's a false good idea to uses the env COMPOSER, and that it is preferable to use the working directory of Composer, and it's is already the case. However, I am always open to discuss in the event you have a native solution to NPM and Yarn to do your configuration.

I need to study npm/yarn more ... do you know if there's an ENV var like COMPOSER? Doesn't this env var works like a working directory change?

@francoispluchino
Copy link
Member

For NPM or Yarn, the package.json is must be in the root of your project.

However, regarding the node_modules directory, you can change the path with Yarn. But for NPM, the --prefix option does not behave as described ...

@schmunk42
Copy link
Contributor Author

For NPM or Yarn, the package.json is must be in the root of your project.

For composer also, at least if you want to use it as a library/extension.
My use-case is a bit special, because it works in conjunction with Docker volumes and wikimedia-merge plugin - but I'd also be fine with yarn only.

Just raised this, because it "tests" the available config options, will play around more & report....

@francoispluchino francoispluchino removed this from the 1.0.0 milestone Sep 12, 2017
@francoispluchino francoispluchino removed their assignment Sep 12, 2017
@francoispluchino
Copy link
Member

I will add the manager-options option to avoid adding the same option twice for the install and update commands.

@francoispluchino
Copy link
Member

The manager-options option is added by 44e0a54.

@schmunk42
Copy link
Contributor Author

I can confirm it is working fine with yarn and --modules-folder (note the s) in manager-options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants