sysgears / spinjs

SpinJS is now Zen! The project has been renamed and moved to Larix Framework.
https://github.com/sysgears/larix/tree/master/packages/zen
MIT License
43 stars 8 forks source link

Introduce interactive prompt to add missing dependencies #15

Open larixer opened 6 years ago

larixer commented 6 years ago

Right now if some build tool dependency is missing the user will face module not found error. It would be much more user-friendly to do the job of installing missing dependencies by spinjs, provided user consent to do so was recevied

blujedis commented 6 years ago

@vlasenko so I have a large proj spinning up (bear with me here) and have been developing a build tool similar to spin since we'll need to fire off a lot of mini/sub projects. Make it easier on the team. First took a run at Parcel but to be honest it's just not ready IMO. Went back to webpack and got pretty far along...

Nearly every runner, build tool whatever you want to call it are often coupled with a specific "starter" or "boilerplate". Invariably causing you to run into some issue where the dev's opinion's good or bad don't fit your project.

The moral here is I think my time in this space would be better suited contributing to Spinjs. Particularly since you've embraced Typescript which in my opinion is the only way to fly.

Give me a bit a time to get a handle on Spin and I'll contrib some meaningful PR's. Happy to tackle this one. If you have any direction/thoughts on implementation let me know.

larixer commented 6 years ago

@blujedis Yes, we need something not coupled to the specific framework and the tool that frees each member of the team from dealing with various build tools and compilers setting up. Moreover we need to jump into new frameworks over time and we want this process to be as painless as possible, by encapsulating at least build tools setup into one place - spinjs.

One more thing that we want is to make our applications modular, with very low price of creating and maintaining the module in the project. So that there were clear boundaries of responsibility and specialization between team members. Ideally one feature of the project = one module. And though the idea looks very simple the TypeScript/JavaScript tools though being themselves fantastic do not really support development of final application as a set of decoupled modules easily.

Of course, the help with spinjs development is greatly appreciated. And this issue, I think, is the most critical at the moment, to enable better spinjs adoption among users. Though you probably have your own priorities.

blujedis commented 6 years ago

As to adoption, I'm a fairly experienced guy and yet I hadn't heard of Spin until two days ago. So I think you're spot on as to what's needed for adoption.

Adoption is honestly more about ease of use and docs. Lot of talented folks in our world the problem is none of us have time to spend combing through source. Meaning if it isn't easy/painless we move on, not because it isn't good, the right fit, but out of necessity due to time constraints.

As to Typescript, yes it can get sticky, yes it's easier, faster without it to be honest, but it makes a world of difference when developing in teams not to mention refactoring. It's also hugely helpful a year or two from now.

Anyway my deadline was in two weeks, and to get what I have now where Spin is wouldn't be possible, so I think I'll embrace Spin. The approach with spin is largely what I was after. A good balance between configurability and plug-n-play.

I'll be giving this a fair amount of time for the next 10 days or there about. Tackling a task such as this is often the best way to really understand a project.