Conflict with fly package

[ghost]

According to wendux/fly#45 I was brought into awareness that there exists a conflict between both Flightplan and Fly.

I wouldn't worry just yet, but due to the fact the issue was brought twice over in the Fly HQ, I thought I would bring it up here as well just to spread awareness.

Workarounds on my side

• Do nothing.
• Symlink bin/index.js to a another name fyl, fl, fy, etc.
• Add a script to package.json that symlinks this out of the box so you can do npm run symlink2.
• Either Flightplan or Fly could make a concession and change the CLI name. I was able to obtain the fly package in the npm registry so having you first npm i fly and then run Fly with a name other than fly would be amusing at best though 😜

After Thoughts

On a different note though. I wonder how challenging it would be to write a Flightplan for Fly or viceversa and starting a collaboration effort between both projects. 🎆

[pstadler]

I agree with the idea that npm install -g fly and then using fly as the command to launch tasks makes sense. On the other hand flightplan was released in early 2014 and was using fly ever since. Because of the fact that we both seem to be stuck with fly we should collaborate.

A possible solution would be to detect and handle if there's either a flightplan.js or Flyfile.js and execute it no matter which fly command is linked globally. If both files exist we could prompt the user to clarify which file he wants to use. If we do this we could probably create a separate module and get both the ownership for it. From my side this shouldn't be a problem, do you think this is doable?

[ghost]

On the other hand flightplan was released in early 2014...

😅 Yes, indeed.

From my side this shouldn't be a problem, do you think this is doable?

Of course.

A possible solution would be to detect and handle if there's either a flightplan.js or Flyfile.js and execute it no matter which fly command is linked globally. If both files exist we could prompt the user to clarify which file he wants to use.

This is one solution with a minor perf penalty. Another thing we could do would be to check whether one is already installed (during the first time install or run) and prompt the user to resolve the conflict.

What about local installations? If the user has node_modules/.bin on her $PATH, then it should shadow a global installation correct?

I went ahead and published conflict on npm meanwhile we figure out a viable conflict resolution. I'll add you as an owner there as well.

[pstadler]

What about local installations? If the user has node_modules/.bin on her $PATH, then it should shadow a global installation correct?

That's true. But then again if you install both projects locally you'll run into to the same problem. It's a mess.

What's the purpose of the conflict module?

[ghost]

The conflict mode would be a module to help users that present a name conflict like we are now. It's just a tentative name and there still no code.

That's true. But then again if you install both projects locally you'll run into to the same problem. It's a mess.

True. I think we can give this issue low priority, however I would keep it open just to remind me I have to get around it at some point. I don't know how stable things are around here, but dev is still pretty crazy over at Fly and I am getting ready to release a new version soon 😄

[pstadler]

Flightplan is pretty stable. I'm planning to change the API to use orchestrator or a similar approach at some point, but I'm hesitating rewriting bigger parts because of ES6 generators. Interestingly, that's exactly the approach you're taking with Fly which opens quite some possibilites.

I'm even thinking about writing flightplan-next as a Fly module. The fact that this project is not yet very stable is not helping much. How would you write such a module?

[pstadler]

Related: npm/npm#7130

[ghost]

@pstadler Please let me say that again in a different way, development over at Fly is "crazy" in the sense that there is a bunch of new features I am currently working on while other folks are working on the plugin factories and other core members work on the website. I really don't expect the API to change significantly or at all, so in that sense it's more or less stable.

I can help you write a Fly plugin, but what is flightplan-next about? I tried searching your repos, but didn't find anything.

[pstadler]

I'm closing this issue for now, if we find a solution it would be great, but I won't push this any further in the near future.