build: netlify.toml written at "postinstall" not detected by @netlify/build

Describe the bug Hi team. not sure if this is the correct place, but I hope I can find some pointers. Link to issue on the support forum.

As the title says, I am trying to inject a netlify.toml which includes custom plugins before netlify/build, but it doesn’t seem to be detected (i.e looks like its too late for it)

I’m doing this because I want to stop endusers from being able to modify the TOML and because I don’t want the file to be tracked in git so that the endusers dont have to know the inner workings of our product.

Is there any way to write/inject a netlify.toml before the netlify build / config sequence kicks in?

Configuration

"postinstall" script - writes our custom netlify.toml to the root folder i.e /opt/build/repo

"postinstall": "node --eval \"require('@my-org/netlify-toml')\""

Deploy logs

7:39:51 AM: [5/5] Building fresh packages...
7:39:57 AM: $ node --eval "require('@myorg/netlify-toml')"
7:39:59 AM: Created default netlify.toml at /opt/build/repo <------ ✅
7:39:59 AM: Done in 61.65s.
7:39:59 AM: NPM modules installed using Yarn
7:39:59 AM: Started restoring cached go cache
7:39:59 AM: Finished restoring cached go cache
7:39:59 AM: go version go1.14.4 linux/amd64
7:39:59 AM: go version go1.14.4 linux/amd64
7:39:59 AM: Installing missing commands
7:39:59 AM: Verify run directory
7:40:00 AM: ​
7:40:00 AM: ────────────────────────────────────────────────────────
7:40:00 AM:   Netlify Build                                                 
7:40:00 AM: ────────────────────────────────────────────────────────
7:40:00 AM: ​
7:40:00 AM: ❯ Version
7:40:00 AM:   @netlify/build 17.9.2
7:40:00 AM: ​
7:40:00 AM: ❯ Flags
7:40:00 AM:   baseRelDir: true
7:40:00 AM:   deployId: 61128f70de851d43819b2cb8
7:40:00 AM: ​
7:40:00 AM: ❯ Current directory
7:40:00 AM:   /opt/build/repo
7:40:00 AM: ​
7:40:00 AM: ❯ Config file <--- 🚫 Not detecting the netlify.toml we just wrote
7:40:00 AM:   No config file was defined: using default values.
7:40:00 AM: ​
7:40:00 AM: ❯ Context
7:40:00 AM:   production
7:40:00 AM: ​
7:40:00 AM: ❯ Loading plugins <---- 🚫 Not detecting our netlify.toml build plugins
7:40:00 AM:    - @netlify/plugin-nextjs@3.8.0 from Netlify app and package.

*Deploy Log Full failing deploy logs @ deploy id 611316d8bda9b800087268ff

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 17 (9 by maintainers)

Most upvoted comments

The setup you are describing seems key to being able to provide any managed Netlify agency product offering. This definitely is a must-have from an agency standpoint.

👀 💯 + Plus startups building a “starter-driven” offering on top of Netlify.

One thing you would also want, I assume, is the ability to modify the configuration of all existing sites at once. From that angle, having account-level build settings (like “Shared Env Vars” as you mention) seems one possible way to go.

Yes, this was the plan with the node --eval "require('@myorg/netlify-toml')". i.e so we could control config versions via this “netlify-toml” package.

Thanks once again for the long chat and assistance . One of the many reasons we chosen Netlify.

All I could ask for. Thanks once again @ehmicky. It was great chatting and learning through this.

Catch up soon.

Great! Thanks for sharing all that feedback. ❤️

I’ve just shared this feature request with the team and we will be exploring it further as part of another feature coming up on our roadmap.

Yeah thought so! hahah - we’ll take anything right now 🤲

Note: for the configuration to be a private Node module, the Netlify build would need to be configured so it has npm access to it. Would this be feasible with your setup?

Yes this should be ok. We already have our NPM_TOKEN set in the Shared Env Vars

Thanks for the additional feedback.

The setup you are describing seems key to being able to provide any managed Netlify agency product offering. This definitely is a must-have from an agency standpoint.

One thing you would also want, I assume, is the ability to modify the configuration of all existing sites at once. From that angle, having account-level build settings (like “Shared Env Vars” as you mention) seems one possible way to go.

Private plugins might be another challenge since those are managed in package.json, not in netlify.toml nor in the UI build settings at the moment.

I have been reaching out to our product manager @verythorough and support engineer @kaganjd to see if they have additional insights into solving your use case.

Thanks to you @ehmicky. This is great.

Are all the sites using the same account?

Yes, we will provision all the sites through our partner account. - In the future, we may need to support clients providing their own netlify account (but not a priority for year one)

account-level build settings would help out

I think this would be ideal. A bit like the “Shared Env Vars”. It would be great if we could upload a global netlify.toml via the CLI or API. Specially if it supported private plugins 🔥

Would “shareable configurations” be a possible solution? Kindof like ESLint/Prettier shared configuration files.

Yes, in the surface this feels like a good solution, but it would require adding more files to the starter (which again an enduser shouldnt be concerned with in this use case).

Agree that the current config feature may aid in ensuring certain fields configs (that are supported like functions), but it doesn’t solve the bigger abstraction which is the [[plugins]] and the actual tracked file itself.