alternatively, you could create a .npmrc file at the start of your build, which I believe can be used to override various configurations and directory locations. Note that I am not terribly familiar with the syntax, but I am guessing it could look something like this:
The drone yaml aims to be a superset of docker-compose. If there is a construct in the docker-compose file specification  that allows for global environment variables, it is something we would implement in the drone yaml.
If such a construct does not exist in the docker-compose specification it is probably not something we would add to drone at this time.
The .env file is probably not the right fit since it does not automatically pass environment variables to the container. You would need to use substitution, which means you would effectively be setting per-step environment variables, but with substitution syntax (so not really an improvement over what we have today).
Environment variables defined in the .env file are not automatically visible inside containers. To set container-applicable environment variables, follow the guidelines in the topic Environment variables in Compose, which describes how to pass shell environment variables through to containers, define environment variables in Compose files, and more.
Yes I was wondering about this Enterprise feature. We’re still evaluating Drone but the Enterprise as it is now is too expensive. I’d like to discuss the pricing with you after we evaluate the solution. Would love to get some sort of official support plan at a price to match our current Codeship spending and ditch it altogether.