Enonic CLI 3 has been released!

New major version of Enonic CLI is available for download from npm, brew, scoop and snapcraft!

What’s new?

  • A sandbox will be started in dev mode by default, unless --prod flag is provided
  • New “sandbox copy” command makes a copy of an existing sandbox with all the contents
  • New “project test” command executes tests in current project
  • Prompt to start a new sandbox after it’s created

Complete list of all the new features and improvements can be found here. Pay special attention to the upgrade notes.

If you are on an earlier version of CLI, simply run enonic upgrade in your terminal (snapcraft users may have to run snap refresh enonic). If you don’t have CLI yet, read here how to install.

3 Likes

Hi guys!

Great job on the 3.0.0 version! :tada:


I have a few issues with the Snapcraft CLI on Ubuntu.

  1. enonic project deploy --c produces error:
    Deploying to sandbox 'item'...
    Watching the file system is not supported.
    
    FAILURE: Build failed with an exception.
    
    * What went wrong:
    Continuous build does not work when file system watching is disabled
    
    * Try:
    > Run with --stacktrace option to get the stack trace.
    > Run with --info or --debug option to get more log output.
    > Run with --scan to get full insights.
    > Get more help at https://help.gradle.org.
    
    BUILD FAILED in 414ms
    
  2. Trying to run tests from the CLI (e.g with enonic project test) produces the following error. Note that running tests from Gradle works fine. Googleing the stacktrace gives hits on trying to run the tests with JRE instead of JDK. I don’t know if this is relevant for you.
    > Task :test
    
    no.item.SortTest > initializationError FAILED
    java.lang.RuntimeException at ScriptRunner.java:141
    Caused by: java.lang.IllegalStateException at PluginLoader.java:84
    Caused by: java.lang.IllegalStateException at DefaultMockitoPlugins.java:105
    Caused by: java.lang.reflect.InvocationTargetException at NativeConstructorAccessorImpl.java:-2
    Caused by: org.mockito.exceptions.base.MockitoInitializationException at InlineDelegateByteBuddyMockMaker.java:260
    Caused by: java.lang.IllegalStateException at ByteBuddyAgent.java:706
    
    no.item.ZipCodeToEmailTest > initializationError FAILED
    java.lang.RuntimeException at ScriptRunner.java:141
    Caused by: java.lang.IllegalStateException at PluginLoader.java:84
    Caused by: java.lang.IllegalStateException at DefaultMockitoPlugins.java:105
    Caused by: java.lang.reflect.InvocationTargetException at NativeConstructorAccessorImpl.java:-2
    Caused by: org.mockito.exceptions.base.MockitoInitializationException at InlineDelegateByteBuddyMockMaker.java:260
    Caused by: java.lang.IllegalStateException at ByteBuddyAgent.java:706
    
    2 tests completed, 2 failed
    

Hi Tom!

Thanks for reporting this.

  1. Usual question - did it work before you upgraded CLI? Snapcraft is always very strict about permissions so it’s possible it never worked at all. You can also try this (for fun) and see if it makes any difference:

enonic project gradle deploy -t

  1. You said that running tests from Gradle works fine. How do you run tests with Gradle - gradlew test?
  1. I haven’t tried this in a long while, so I honestly don’t know.

  2. Running tests trough the CLI did not work before the upgrade either. It workes fine when I do ./gradlew test or ./gradlew build.

Hello,
I recently upgraded to CLI 3.
I run enonic project clean and then enonic project deploy and my application builds successfully.
If your sandbox is not running, it would promt Do you want to start sandbox 'somesandbox'? [Y/n]
And if you choose Y it would boot up your sandbox.
I guess this would be prod mode in versions prior to CLI 3.

The problem now, is that my application fail with a bunch of Expected an operand but found ) errors in dev mode, but in prod mode they don’t fail on this.

Example:
( Works in prod but not dev )

    return handleError(
      "Task is already running, wait for task to finish before running it again",
      400,
    );

I think its related to formatting and this would then work in both cases.

    return handleError("Task is already running, wait for task to finish before running it again", 400);

Example of stacktrace

Caused by: org.openjdk.nashorn.internal.runtime.ParserException: someapp:/main.js:27:0 Expected an operand but found )
);
^
	at org.openjdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:293)
	at org.openjdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:278)
	at org.openjdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:4418)
	at org.openjdk.nashorn.internal.parser.Parser.expression(Parser.java:4568)
	at org.openjdk.nashorn.internal.parser.Parser.conditionalExpression(Parser.java:4720)
	at org.openjdk.nashorn.internal.parser.Parser.assignmentExpression(Parser.java:4659)
	at org.openjdk.nashorn.internal.parser.Parser.argumentList(Parser.java:3703)
	at org.openjdk.nashorn.internal.parser.Parser.leftHandSideExpression(Parser.java:3385)
	at org.openjdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:4397)
	at org.openjdk.nashorn.internal.parser.Parser.expression(Parser.java:4568)
	at org.openjdk.nashorn.internal.parser.Parser.conditionalExpression(Parser.java:4720)
	at org.openjdk.nashorn.internal.parser.Parser.assignmentExpression(Parser.java:4659)
	at org.openjdk.nashorn.internal.parser.Parser.expression(Parser.java:4537)
	at org.openjdk.nashorn.internal.parser.Parser.expressionStatement(Parser.java:1840)
	at org.openjdk.nashorn.internal.parser.Parser.statement(Parser.java:1146)
	at org.openjdk.nashorn.internal.parser.Parser.sourceElements(Parser.java:900)
	at org.openjdk.nashorn.internal.parser.Parser.functionBody(Parser.java:4165)
	at org.openjdk.nashorn.internal.parser.Parser.functionExpression(Parser.java:3795)
	at org.openjdk.nashorn.internal.parser.Parser.memberExpression(Parser.java:3553)
	at org.openjdk.nashorn.internal.parser.Parser.leftHandSideExpression(Parser.java:3382)
	at org.openjdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:4397)
	at org.openjdk.nashorn.internal.parser.Parser.expression(Parser.java:4568)
	at org.openjdk.nashorn.internal.parser.Parser.conditionalExpression(Parser.java:4720)
	at org.openjdk.nashorn.internal.parser.Parser.assignmentExpression(Parser.java:4659)
	at org.openjdk.nashorn.internal.parser.Parser.expression(Parser.java:4537)
	at org.openjdk.nashorn.internal.parser.Parser.primaryExpression(Parser.java:2797)
	at org.openjdk.nashorn.internal.parser.Parser.memberExpression(Parser.java:3598)
	at org.openjdk.nashorn.internal.parser.Parser.leftHandSideExpression(Parser.java:3382)
	at org.openjdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:4397)
	at org.openjdk.nashorn.internal.parser.Parser.expression(Parser.java:4568)
	at org.openjdk.nashorn.internal.parser.Parser.conditionalExpression(Parser.java:4720)
	at org.openjdk.nashorn.internal.parser.Parser.assignmentExpression(Parser.java:4659)
	at org.openjdk.nashorn.internal.parser.Parser.expression(Parser.java:4537)
	at org.openjdk.nashorn.internal.parser.Parser.expressionStatement(Parser.java:1840)
	at org.openjdk.nashorn.internal.parser.Parser.statement(Parser.java:1146)
	at org.openjdk.nashorn.internal.parser.Parser.sourceElements(Parser.java:900)
	at org.openjdk.nashorn.internal.parser.Parser.program(Parser.java:835)
	at org.openjdk.nashorn.internal.parser.Parser.parse(Parser.java:322)
	at org.openjdk.nashorn.internal.parser.Parser.parse(Parser.java:282)
	at org.openjdk.nashorn.internal.runtime.Context.compile(Context.java:1484)
	at org.openjdk.nashorn.internal.runtime.Context.compileScript(Context.java:1451)
	at org.openjdk.nashorn.internal.runtime.Context.compileScript(Context.java:761)
	at org.openjdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:528)
	at org.openjdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:517)
	at org.openjdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:395)
	at org.openjdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:151)
	at java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:231)
	at com.enonic.xp.script.impl.executor.ScriptExecutorImpl.doExecute(ScriptExecutorImpl.java:189)
	... 10 common frames omitted

Is this a bug?

In dev mode JS engine reads source files directly from their origin (not from inside the assembled JAR file). The problem with your syntax is that you have a dangling comma (“400,”) which strict rules of the engine would not accept. You probably have a build config which removes dangling commas build-time, that’s why you don’t get this error in prod mode.

So you can either remove dangling commas, or deploy your project with enonic project deploy --prod, which will start the sandbox in prod mode.

I see, makes sense. Thanks :+1:

That trailing comma might come from Prettier.

I encountered that problem in the project I’m working on now. The solution was to add "trailingComma: "es5" to the projects .prettierrc.json