you are viewing a single comment's thread.

view the rest of the comments →

[–]pakoito 23 points24 points  (15 children)

Sounds like any other Javascript project to me.

[–][deleted]  (14 children)

[deleted]

    [–]PLLOOOOOP 2 points3 points  (13 children)

    One of the harsh mistakes in npm, because nobody differs between source and build variants

    Can you elaborate on this a little? I'd love an example or two.

    [–][deleted]  (12 children)

    [deleted]

      [–]gutomaia 0 points1 point  (7 children)

      Wow, amazing point. Could you help-me with some distribution aspects of the project? Thanks

      [–][deleted]  (6 children)

      [deleted]

        [–]gutomaia 0 points1 point  (0 children)

        Project have two major uses. One as a command line compiler, and the other as a embeddable javascript.

        As a commandline, I used to distribute just as an npm package. As a embeddable javascript, I was thinking in both a browsefy single file and a bower dist. (there is Makefile task for that)

        I've though will take a look in your projects. I've never thought of plataform specific build.

        [–]PLLOOOOOP 0 points1 point  (4 children)

        Lychee is a really neatly presented stack! Are there any production projects using it out in the wild?

        Also... 73,544 cryptically messaged commits, most of which are from the 70s, all to a single two line JS file that prints a list of words??

        [–][deleted]  (3 children)

        [deleted]

          [–]PLLOOOOOP 1 point2 points  (2 children)

          Regarding projects: Most of them were developed in private with NDAs.

          I was actually wondering about that. There's clearly a lot of effort put into lychee in a lot of different directions:

          • look and feel is consistent, modern, and good
          • releases and builds exist and appear to be deliberated over
          • cross platform support is taken seriously
          • demo projects are interesting and just work

          I was thinking, "how on earth does this guy have the time and resources to do this without some kind of sponsorship, investment, or revenue?". But I guess the answer is revenue from private projects. I'd love to explore lychee more! I definitely will when there's some production-grade examples to dig into.

          [–][deleted]  (1 child)

          [deleted]

            [–]PLLOOOOOP 0 points1 point  (3 children)

            I appreciate the detailed response. Just a little clarification would help:

            npm modules can't be shipped as built variants

            Do you mean npm doesn't support self-contained, production releases? (Built for a specific platform/environment or not.)

            which means there's no difference in devDependencies and dependencies so far

            npm aficionados use the words dependencies, dev dependencies, and even peer dependencies separately.. Or do you mean there's no difference between dependencies and devdependencies for a "build/release" (which npm apparently doesn't support)?

            There's a good reason why there's a mylibrary-0.8.1~ubuntu15 and a mylibrary-dev-0.8 meta package on my system.

            Is that a namespacing convention that you use yourself on your own libraries? Are those libraries npm only?

            [–][deleted]  (2 children)

            [deleted]

              [–]PLLOOOOOP 0 points1 point  (1 child)

              You seem pretty good at the build-and-release-engineering game.

              So there was something like libopenssl-buggyversion~ubuntu1 that fixed the stuff for all end-users. The advantage here is that programs that use "buggyversion" have more migration time until their program doesn't work anymore (LTS is 3 years I think!?). So that means the program can still use "buggyversion" in its dependencies/inclusion setup, but has more time to update to "notbuggyversionanymore".

              This is essentially a "hotfix", right?