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

[RFC] Don't start dev server for non-html entry points? #1005

Closed
davidnagli opened this issue Mar 15, 2018 · 8 comments
Closed

[RFC] Don't start dev server for non-html entry points? #1005

davidnagli opened this issue Mar 15, 2018 · 8 comments

Comments

@davidnagli
Copy link
Contributor

Currently, when you run parcel with --target set to node, it starts a static dev server on port :1234. This doesn't really make sense for Node bundling, since we don't expect the code to run in the browser.

Is anybody opposed to disabling the dev server for node bundling?

@davidnagli davidnagli added this to Discussion in RFC via automation Mar 15, 2018
@DeMoorJasper
Copy link
Member

This is definitely not very usefull, might be a good idea to add in a check to prevent this, no need to start servers for no reason

@davidnagli davidnagli moved this from Discussion to Design in RFC Mar 16, 2018
@davidnagli davidnagli moved this from Design to Implementation in RFC Mar 16, 2018
@davidnagli davidnagli added 🙏 Help Wanted Good First Issue and removed 💬 RFC Request For Comments labels Mar 16, 2018
@lili21
Copy link
Contributor

lili21 commented Mar 16, 2018

I can take a look.
Question, should I change the serve command, or should I change the default command to build when --target set to node ?

@DeMoorJasper
Copy link
Member

DeMoorJasper commented Mar 16, 2018

@lili21 Node.js should just watch and auto-recompile when doing anything but build imo.
It shouldn't startup the server but simply watch and rebuild changed assets

@davidnagli
Copy link
Contributor Author

@DeMoorJasper Actually, maybe we should just not start the dev server for ANY non-html entry points, regardless of the target.

So if I run parcel index.js even without --target node, there's still no point in starting a dev server for a JS file (as far as I see)

@DeMoorJasper
Copy link
Member

@davidnagli that’s actually a good point, as far as I know you’re right

Sent with GitHawk

@mischnic
Copy link
Member

mischnic commented Mar 17, 2018

#935 is a duplicate (but also talks about electron)?

@davidnagli davidnagli changed the title [RFC] Don't start dev server for Node bundling? [RFC] Don't start dev server for non-html entry points? Mar 17, 2018
@nicolaisueper
Copy link
Contributor

nicolaisueper commented Mar 28, 2018

I don't know really much about HMR, but should it be disabled too? Sry, I see it is already disabled on node targets.

@posidron
Copy link

posidron commented Sep 9, 2018

Hi, after a lot of trial and error I found this issue here.

The below worked till 1.7.1 but with the next release of 1.8.0 it didn't (incl the current 1.9.7). Reason, the dev server did not get launched anymore for the parcel:launch command.

    "start": "run-p -r parcel:launch electron:launch",
    "parcel:launch": "parcel src/renderer/index.html -p 1124 -d dist/renderer/development --target=electron",
    "electron:launch": "run-s parcel:main electron:start",
    "parcel:main": "parcel build src/main/main.ts -d dist/main --out-file=main --target=electron",
    "electron:start": "electron ."

I am not familiar about all the internals of Parcel but, should the patch not be more like:

  if (command.name() === 'serve' && (command.target === 'browser' || command.target === 'electron')) { ...

With that modification it works as expected.

Is the possible solution of @rkpatel33 (btw. thanks for those documented trial and error cases. It made me feel not alone!) to make use of the API the only way now? It seems a bit bloated for something what could be a single command?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
RFC
  
Done
Development

Successfully merging a pull request may close this issue.

6 participants