vercel: [now dev] Error! Your codebase isn’t linked to a project on ZEIT Now.

Hi @gadicc

This is the intended behavior.

Now CLI 17.x.x introduced Project Linking so that build and dev commands live in the project dashboard.

You link your source code to a project once and then you can run now dev.

Would be awesome to be able to share my repository with others (public or private) and allow them to use now dev without giving them privileges to deploy. I had to downgrade now to 16.x to work with someone 😦

Besides my use case, open-source websites could use now for deployment and allow random contributors to use now dev to develop locally including its serverless functions API.

I would greatly appreciate it if this use case was considered. now dev is an amazing tool.

@styfle how to perform codebase link without deploy?

I think that:

• now dev should read package.json and now.json if it/they exists (just like it did before v17)
• The cloud should also read package.json and now.json if it/they exists (just like it did before v17)
• IF package.json and/or now.json does not exist, the new semantics of this new “project linking” should happen.

So basically, leave it as it was for those of us that have used Now pre-17 and use a proper package.json + now.json approach. We do NOT have a problem that needs solving regarding “how to build the deploy” or “how to configure build and development settings”, it is already working. You said it yourselves in the blog post

we’re extending this process to non-JavaScript projects

You should’ve done this without a breaking change to now and now dev regarding “project linking”. The way you implemented this with v17 is more like

we’re replacing this process for JavaScript projects so that we can better support non-JavaScript projects even though we are making the experience for JavaScript projects worse

Just have “project linking” use the values from package.json and now.json if they exist (in the deployment and locally) (like Now has been doing for quite some time now), if they don’t exist you trigger this new “project linking” flow.

I can’t imagine the majority of your customers being “non-JavaScript projects” that it would warrant this breaking change to all your “JavaScript project” customers. I mean you have to have more customers deploying Next.js and Gatsby then you have deploying Hugo and Jekyll, no? And even if you don’t, why not just improve the experience for non-JavaScript projects without degrading it for JavaScript projects.

Recently it has felt like you have been making the world a better place 2-steps-forward-and-1-step-back at a time 😕

For CI/CD you can also use NOW_ORG_ID and NOW_PROJECT_ID environment variables.

See https://spectrum.chat/zeit/now/solved-project-linking-and-ci-cd-pipelines~5e6eb62a-9d56-47ac-9e32-0d973a523787

Why force a remote “link” to establish Project Settings when now.json is an established pattern for setting configuration?

It seems to me that now should check for the settings in now.json. If there’s a link established then it can check there too.

One can override the other; my vote would be that now.json “disables” the fields in the dashboard.

I’d like to add one point of view here, which I didn’t entirely realize previously.

One of the things which we sadly lost by this update is the simplicity of going to a directory and typing now to just deploy the contents. After the update, now becomes an interactive “wizard” with questions, which somehow reminds me more Windows XP program installations than ZEIT’s focus on simplicity.

I have materials where I teach beginners in programming the concept of web APIs. There is grand finale in deploying your own API to the internet. I’m using ZEIT Now to achieve that and I love it for its simplicity of installation and deployment. During the workshop, I don’t want people to think about the deployment much, I want them to just type now and see URL. They usually don’t have any serious experience with deploying stuff. After the update, I’ll have to rewrite the tutorial (again…), and instead of a few lines, I’ll have to guide the beginner through all the bumps of the wizard and project linking.

Will ZEIT Now still stay the best platform where to achieve something like this the easiest possible way? Perhaps! But I championed it for this purpose in the first place because of the simplicity of deployment. I could have choose Heroku etc., but typing now was too hassle-free for a workshop lecturer (and a tutorials author) to resist.

@aleclarson It is necessary because now dev needs to know what the “Development Command” is and the “Development Command” defined in the Project Settings.

We’re looking at a solution to create a Project without actually deploying so that you can run now dev.

The canary channel has been updated with a new command, vercel link.

Additionally, vercel dev will ask to link to a project if it is not already.

Try it out now with npm i -g vercel@canary, thanks!

that you’re adding steps in to the cli process is disheartening 😦

now dev will stop requiring a deployment very soon. We’ll be able to detect framework configuration and project settings without deploying at all. This is a problem and it’s on us. https://github.com/vercel/vercel/issues/3767#issuecomment-611074321

So this statement was about specifically not requiring a deployment but not about not requiring a link.

So this issue is closed because now dev prompts for you to use now link but not because the actual issue is solved which is not requiring a link for local dev?

I’ll echo that. When I demo people now when they’re stepping in to serverless for the first time, I want them to avoid the hell that is the native serverless of AWS / GCP. This project linking is moving away from simplicity towards a more complicated solution.

@rauchg Thanks for the reply

1. Fair enough, thanks for the honest reply, I appreciate it.

2. I get your predicament, I really do. What I am trying to get at with many of my posts in the issue queue, spectrum, e-mails, etc. to you and your team is that this info that you are giving here, in this thread (and other threads about other things), to the select few that are following along here is what we need to get in the blog post, in the public announcement. It helps us developers know WHY these changes are needed, most likely we will understand the problem you are solving and have a little more patience and understanding when these sudden errors get thrown in our face by CI, colleagues and trainees. This particular change was HUGE in regards to using the platform. Me and my team of developers lost productivity for a whole day trying to figure out what happened, not cool. Downgrading to v16 felt so bad, but had to be done to get now dev working without losing more time.

Also regarding the dangerous aspect of mapping “name”; when a deploy has happened to a specific name, isn’t that name taken by the user/team that deployed to it? Why can someone else override it? It doesn’t make sense to allow that (unless it is another developer of the same team). If you allow it, can you explain the reasoning behind why? If you don’t allow it and still had customers experiencing unexpected downtime, then I reckon that those customers doesn’t understand the platform correctly and they should get educated, no offense.

Last question, why is the recommendation that .now be ignored by version control? If the problem is the mapping, shouldn’t a repo be “connected” to a project id and have the connection in version control? If it can live in version control, can’t it be set inside now.json? Hehe, sorry, that was three questions.

Thanks in advance 🙏

@styfle and how is this done on CI?

@michaellopez there are two issues we are addressing here:

1. now dev will stop requiring a deployment very soon. We’ll be able to detect framework configuration and project settings without deploying at all. This is a problem and it’s on us.
2. With regards to the requirement of .now, it strictly has to do with making a more resilient system. Mapping “name” is dangerous and entirely relies on the idea that you will never change the project name. It also introduces a potentially fatal problem from an availability perspective: if a developer happens to name a folder the same as your production website, and then runs now --prod, they will basically be overwriting your project.

The second point is really worth stressing. Without .now, we don’t have a project id, just a loose mapping based on name, that has led some customers to unexpected downtime.

The issue with not being able to run now dev locally really needs to be addressed… Codebase needs to be able to run anywhere locally without having to access remote stuff. I’m working around this by running npx now@16.6.3 dev

Personally, I would really appreciate a way to configure all of the project settings from the command-line. For example, I would like to be able to set a production deploy alias on a custom domain without opening up the now website in my browser. I would also like to be able to link the project from command line without a deploy.

Could you add a now project command that allows linking a directory to a project and performs operations on the linked project, such as configuring deploy aliases? Maybe have now project link, now project alias deploy.example.com, and maybe some sort of now project config <property> [value] for setting things like build commands? The now project link command would collect all of the same info that the deploy linking would, send that to the server, and set up the project. You would be able to specify a custom project name with now project link --name example or maybe now project link example and not specifying the name would suggest the directory name but ask for confirmation and allow you to enter a value if you decline the suggestion.

One of the things I like best about now is that I can do everything from the command-line and my config files. Having to go to the website to configure a project is a significant departure from the complete command-line control that I’ve liked so much until recently.

If you would like me to enter a formal feature request describing my imagined now project command, I would be happy to do so. Just let me know.

@rauchg

This is a problem and it’s on us.

For the record I think this is a great response. But why is it 61 DAYS later?

@styfle so like: (?)

vercel link  VERCEL_ORG_ID=$VERCEL_ORG_ID   VERCEL_PROJECT_ID=$VERCEL_PROJECT_ID  --confirm  --token $VERCEL_TOKEN

then we can do vercel dev in CI successfully?

This issue is a bummer. 😦

I want to open source a site and be sure that folks can clone the repo run it locally without a lot of hassle. Since it has a serverless function, vercel dev is used to start it up locally. This can’t be used without jumping through a few more Vercel hoops. 😕

I hope this issue is addressed soon.

v16 doesn’t work anymore for us, it got broken ~7 days ago and won’t get fixed. (see #4332)

@Vadorequest you can fix the versions of the builders as a workaround to this issue. This is an example extracted from my v16 project’s now.json, using last functioning versions:

  "builds": [
    { "src": "admin-api/*.js", "use": "@now/node@1.5.1" },
    { "src": "api/*.js", "use": "@now/node@1.5.1" },
    {
      "src": "web/package.json",
      "use": "@now/static-build@0.16.0",
      "config": { "distDir": "build" }
    }
  ],

@honzajavorek I’m really not a fan of decisions based on users that don’t know how to use something. I do understand that I’m probably in the minority there, but still, there is nothing preventing that same human error from occurring with project linking. It’s just as easy to answer “yes” to all the CLI prompts or drop in a -c / --confirm in the command or set NOW_ORG_ID+ NOW_PROJECT_ID in the environment to get the same “downtime issue” as described. Users that don’t understand something are usually the same users that don’t read the prompts/modals/docs/whatever (that’s the whole point of why they don’t understand what they are using) and would therefore be prone to the same human error rate, with or without project linking.

For me it all comes down to giving the correct permission to the correct users. That’s why I don’t have any of my developers in my Now team, everything is done by CI. I shouldn’t need to trust them or require them to learn skills they aren’t interested in learning, no one should. Again, I understand my opinion might be considered harsh and in the minority.

The change could just as well have been “when deploying to prod (now --prod), ask for confirmation when there already is a deployment aliased to production” (and make it big and shiny, or even better do it like Super Smash Bros. Brawl did it for data deletion). It is essentially the same level of help against human error as this project linking is. Except not as invasive as project linking.

As to .now, I’d say it shouldn’t be in Git because you can have multiple projects attached to one codebase? 🤔 Or are those IDs secrets? Honestly I don’t know. I haven’t really seen any docs/blogs mentioning any recommendation.

Having multiple projects attach to one codebase feel more human error prone than being without project linking. The IDs might be considered secrets, not sure. Now applies access rights properly (both web and deploy) so I’m not sure what an attacker could gain from knowing the IDs. Maybe the ZEIT team can shed some light on this.

The recommendation is obviously to not have them in version control as the CLI has code that makes sure to add .now to your .gitignore, it even informs you of this. Although the catch makes me wonder, hence I’m asking. If the purpose of project linking is to link a codebase to a project it should be in version control. Otherwise the codebase won’t be linked to a project. The clone/working copy on a developers machine will be linked to a project. I reckon that the users that don’t understand the platform will still have a hard problem with the human errors and probably some problems with project linking too 🤷‍♂

By the way, making an initial deploy a.k.a. project linking actually leaves you with a dirty working copy, which feels a bit dirty to me 😃

I’ve recently opened up an issue that details my concerns with the current approach and how I believe things should work instead. Since this and my own issue seem to be quite aligned and to avoid having two issues on the topic I’ll close my issue and re-post it here as-is.

---

It has come to my attention that “now dev is moving towards the use of frameworks and other libraries since this is the most common usage”. These were the exact words from @paulogdm in a support ticket. I’m not sure if I’m the only one that sees now dev differently but I’m here to explain my use case for now dev, as requested by Paulo.

I currently have my home page deployed to ZEIT Now and I’m not using any framework; it’s a basic website built with Gulp.js and I use Browsersync for local development. My website is built with yarn build and there’s nothing I need to do to deploy this to ZEIT, Yarn is detected and it uses the build task in package.json with zero configuration.

However, I have a custom now.json configuration file where I have some security headers specified. Now, how do I test this configuration and make sure the headers are properly configured? I could run now and have a preview version deployed and test the headers online, but now dev allows me to do that locally without deploying anything. Currently, I just have to run now dev on the root of my project and a local HTTP server will be available to me, replicating everything as if I were to deploy to ZEIT Now, but without deploying anything.

This feature is awesome and I’m hereby requesting that you don’t remove it. Please keep supporting now dev for framework-less projects. I can’t be alone using ZEIT Now and now dev without a framework, can I?

As an extension of the above, I have a feature request to improve local development based on now dev. You might have noticed the following in my now.json file above:

"builds": [
  {
    "use": "@now/static-build",
    "src": "package.json",
    "config": {
      "zeroConfig": true,
      "outputDirectory": "dist"
    }
  }
],

I understand that the above is deprecated, however, now dev - on framework-less/custom projects - is defaulting to public and the above was the only way I found that allowed me to change the output directory (I use dist by convention and I really would like to keep it that way).

The same way you allow the BUILD COMMAND, OUTPUT DIRECTORY and DEVELOPMENT COMMAND to be overridden for deployments to ZEIT Now:

I propose that now.json allows one to configure/override those 3 options to be read by now dev at least, if overridden, of course.

What I meant with “at least” above is that these options could also be read by now (or now --prod) and be used to override the UI options in “Build & Development Settings” above. And the UI could reflect that by displaying the overridden option value and changing the toggle to blue (as if it was overridden directly in the UI). However, to avoid having the UI overrides out-of-sync with the now.json options, the input fields and the blue toggles should be disabled (slightly faded out perhaps) not allowing changes in the UI with a little message saying something like “this is overridden in now.json please remove/change it there”.

What does everyone think about this?

You link your source code to a project once and then you can run now dev.

Hey @styfle, can you explain why that’s necessary? Isn’t now dev strictly local?

While trying to link the projects (which is a step I do not want to do) I’m getting the following error:

❗️  The `name` property in now.json is deprecated (https://zeit.ink/5F)
Error! SHA1 sum of the file (b196187a451fb8eb6c3c89b2097f7154a7c8534c) doesn't match the provided SHA1 sum (2fd6d71392316dae9ef96b0a9324d34b08d14067)

Thanks @styfle it will very handy for development purposes

That’s not possible at this time. I’ll send your feedback to the team, thanks!

You can use the –confirm option to skip these questions.

Canary version works good for me! My GitHub actions code is below.

- name: Install Vercel
  run: yarn global add vercel@canary

- name: Pull env from Vercel
  run: vc env pull -t ${{ secrets.VERCEL_TOKEN }}
  env:
    NOW_ORG_ID: ${{ secrets.ORG_ID }}
    NOW_PROJECT_ID: ${{ secrets.PROJECT_ID }}

- name: Run vercel dev
  run: vc dev -t ${{ secrets.VERCEL_TOKEN }} &
  env:
    NOW_ORG_ID: ${{ secrets.ORG_ID }}
    NOW_PROJECT_ID: ${{ secrets.PROJECT_ID }}

Thanks @Vadorequest, I’d be OK with this as a fix, but I’m not using the next.js framework at all.

Are we suppose to use the --confirm option in our CI deployment ? This changement has broke my CI deployment…