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

cli: compile command / auto-compile packages #98

Closed
joeduffy opened this issue Feb 23, 2017 · 3 comments
Closed

cli: compile command / auto-compile packages #98

joeduffy opened this issue Feb 23, 2017 · 3 comments
Assignees
Labels
area/tooling impact/usability Something that impacts users' ability to use the product easily and intuitively

Comments

@joeduffy
Copy link
Member

joeduffy commented Feb 23, 2017

If you do a Pulumi operation, but the package's write timestamp is older than any of the project's files, we should probably warn about this. It's all too easy to make a code change, think you're applying that change, but then realize you forgot to recompile the package. (I've done it.)

@joeduffy joeduffy added area/tooling impact/usability Something that impacts users' ability to use the product easily and intuitively kind/suggestion labels Feb 23, 2017
@joeduffy joeduffy added this to the S10 milestone Feb 23, 2017
@joeduffy
Copy link
Member Author

joeduffy commented Mar 6, 2017

@lukehoban pointed out that it's probably nicer to just do the recompilation, rather than issuing a warning. I agree. We probably want a --no-rebuild option for developers who want to intentionally suppress the rebuild, however, I'd expect it to be rarely used and thus the wrong default behavior.

@joeduffy joeduffy changed the title Issue a warning if the MuPackage is out of date mu compile: Command and auto-compile MuPackages Mar 10, 2017
@joeduffy joeduffy changed the title mu compile: Command and auto-compile MuPackages coco compile: Command and auto-compile MuPackages Apr 3, 2017
joeduffy added a commit that referenced this issue May 18, 2017
This change keeps the lumi prefix on our CLI tools.

As @lukehoban pointed out in person, as soon as we do #98,
most people (other than compiler authors themselves) won't actually be
typing the commands.  And, furthermore, the commands aren't all that bad.

Eventually I assume we'll want something like `lumi-js`, or
`lumi-js-compiler`, so that binaries are discovered dynamically in a way
that is extensible for future languages.  We can tackle this during #98.
@joeduffy joeduffy self-assigned this May 24, 2017
joeduffy added a commit that referenced this issue May 24, 2017
This consolidates the multiple project files we have right now, embellishing
further the Lumi.yaml/json project file as the place for all things project
and package related.  Although I suspect we will revist some of this during
next sprint's package management work, this is a step in the right direction.

As a result, we can rip out all the tsconfig.json files scattered throughout.

The new structure adds two top-level sections to the Lumi.yaml/json file:

    language:
        compiler: lumixx
        settings:
            a: foo
            b: bar
            z: baz
    files:
        - index.xx
        - config.xx

The idea here is that the manifest self-describes three things: 1) the compiler
used to build the package, 2) the settings to pass to that compiler (an opaque
bag to Lumi, since these are specific to the compiler), and 3) the source files
that comprise the project.  This helps to unify the different compilers.

This accomplishes work item #49.  It also enables #98,
the `lumi compile` and automatic recompilation commands, which will come soon.
@joeduffy joeduffy changed the title coco compile: Command and auto-compile MuPackages lumi compile: Command and auto-compile MuPackages May 24, 2017
@joeduffy joeduffy modified the milestones: 0.3, 0.2 May 26, 2017
@joeduffy joeduffy modified the milestones: 0.5, 0.3 Jun 5, 2017
@joeduffy joeduffy changed the title lumi compile: Command and auto-compile MuPackages cli: compile command / auto-compile packages Aug 4, 2017
@joeduffy joeduffy removed this from the 0.5 milestone Aug 19, 2017
@ellismg
Copy link
Contributor

ellismg commented Jan 15, 2018

We've already started down the path of "enlightening" pulumi based on the current project type (for example, not uploading dev dependencies). If we taught the tool to run "npm run-script build" iff there was a package.json file with a "build" event in the "scrupts" section, would that be sufficient?

@joeduffy
Copy link
Member Author

We have basically accomplished this thanks to the first class TypeScript support.

jkodroff pushed a commit to pulumi/pulumi-docker-containers that referenced this issue Oct 4, 2021
This change keeps the lumi prefix on our CLI tools.

As @lukehoban pointed out in person, as soon as we do pulumi/pulumi#98,
most people (other than compiler authors themselves) won't actually be
typing the commands.  And, furthermore, the commands aren't all that bad.

Eventually I assume we'll want something like `lumi-js`, or
`lumi-js-compiler`, so that binaries are discovered dynamically in a way
that is extensible for future languages.  We can tackle this during #98.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/tooling impact/usability Something that impacts users' ability to use the product easily and intuitively
Projects
None yet
Development

No branches or pull requests

3 participants