apollo service:push fails because it makes assumptions about the environment #1132
Comments
|
@ThomWright interesting... loading env variables from For those reasons, I don't think |
|
Well, the simple fix is to not assume that |
|
Yeah, I think that's pretty reasonable :) regardless of what we do, we shouldn't be failing out if something's not what we expect |
- Fixed bug where a user specifies loading of a config with a flag, but if that file isn't found, it loads an `apollo.config.js`. - Ex: `apollo client:check --config=config/apollo.js` would also load `./apollo.config.js` if it couldn't find the specified config. I think if a user is _manually specifying_ a config, it should _only_ load what they specified and throw an error if not found. - This was preventing testing errors, since leaving off a config would just load this repo's config (which wouldn't work) - Removed the `getSearchPlaces` function. It was extraneous, and misleading. While `search places` is the term that dotenv uses, it is less descriptive than `defaultFileNames`, since that what the search places are–filenames. - Added `try/catch` around the cosmiconfig's loader, since it can throw on malformed files with an unhelpful error. - Handled case where `.env` is not a `File`, but a folder or something else. Resolves #1132 - Split up project type and service name setting, since those being intertwined added unnecessary complexity
Intended outcome:
Successful
apollo service:pushActual outcome:
Failed
apollo service:pushHow to reproduce the issue:
Create an empty directory called
.envin the root of the project and runapollo service:push.Versions
apollo@2.6.2apollo-language-server@1.5.4Culprit
The precise problem is that
apollo-language-serverchecks for the existence of.env, and assumes that if it exists then it is a config file it can read. In this case it is a directory. In fact, it could be a directory or a completely irrelevant file.In general the problem is that
apollo-language-servertries to make guesses about the environment it's running in. I would much prefer to configure it with explicit arguments (to the CLI, which are passed to theapollo-language-serverlibrary). I would rather it didn't look at my files, or my environment variables.I should be able to be free to do what I want with my environment without worrying about nested dependencies looking at it and breaking.
The text was updated successfully, but these errors were encountered: