Is it possible to compile ES6 modules to IIFE similar to how the iife output option of Rollup works?
I found a plugin babel-plugin-transform-modules-iife, which was inspired by the iife option of rollup. But the plugin just wraps the module source in an IIFE, and expects the imported module to be already loaded, whereas Rollup merges the imported module source to the bundle output.
Related
My team and I are currently working on a project where we have injected the joost-de-vries plugins to compile our typescript files.
Everything was working fine until we had to use the angular2-jwt dependency which contains ts files. The problem is that those files are getting compiled even though they are not included in rootDir and included in the excluded folders.
When compiling we get the following mistake :
TS6059 File 'path/to/file' is not under 'rootDir' 'rootDir/path'. 'rootDir' is expected to contain all source files.
As a consequence, the ts files are compiled as empty folders (with a js extension though). The rootDir compiler option is definitely the key to it but we can't seem to find any solution after a long week of research and tries. Is there already a workaround the fact that rootDir is an ignored compiler option? If not is it a work in progress or can we do anything about it?
About our project, we are using the Play 2.5.4, Scala 2.11.8 and are using the latest versions available on webjars for angular2 RC4 (basically the webjars used in play-angular2-typescript from joost-de-vries).
Thanks in advance for your answers.
Suppose I have a Scala compile-time macro that I find useful and would like to share it (I do). How do I create a JAR file that when loaded into another project would execute the macro when compiling the new project?
Specifically, I've made a StaticAnnotation that rewrites the AST of the class that it wraps before compile time. This works in my Maven build (macro defined in the main directory, runs on test cases in the test directory) because I have
<compilerPlugins>
<compilerPlugin>
<groupId>org.scalamacros</groupId>
<artifactId>paradise_2.10.5</artifactId>
<version>2.1.0-M5</version>
</compilerPlugin>
</compilerPlugins>
in my scala-maven-plugin. (I'm starting with a Scala 2.10 project and if it works, will provide both 2.10 and 2.11.)
But if I put the resulting JAR on a Scala console classpath, in a Scala script, or into another Maven project (without special compiler plugins), it simply ignores the macro: the AST does not get overwritten and my compile-time println statements don't execute. If I use the #compileTimeOnly annotation on my macro (new in Scala 2.11), then it complains with the #compileTimeOnly error message.
Do I really need to tell my users to add compiler plugins in their pom.xml files, as well as alternate instructions for SBT and other build tools? Other packages containing macros (MacWire, Log4s) don't come with complicated build instructions: they just say, "point to this dependency in Maven Central." I couldn't find the magic in their build process that makes this work. What am I missing?
If you're relying on a macro-paradise-only feature then yes, you do need to tell your users to add compiler plugins. See http://docs.scala-lang.org/overviews/macros/annotations.html . The projects you mention are only using the scala compiler's built-in (non-paradise) macro features, not macro annotations.
I was refactoring the package structure inside a scala project with eclipse. In the middle of this I used a package statement with _root_, like this
package _root_.com.workday.foo.bar
Now my eclipse project will not build although I can still build everything in the command line. The problem is that all my com.* imports are broken
import com.workday.some.thing.Else
The error is:
Multiple markers at this line
- object workday is not a member of package com.workday.foo.bar.com
- object workday is not a member of package com.workday.foo.bar.com
It appears that it is trying to find all imports relative to the package statement at the top of each source file.
I have removed the _root_ from my package and tried to clean my project and the workspace. I have also tried changing the scala compiler from "sbt" to "refined" and back but to no avail
Does anyone know how to kick the eclipse scala compiler back on track???
Sorry to answer my own question so quickly, but I discovered the problem.
I had a sub package defined in the middle of a source file that contains various mock classes, this sub package had been changed to com.workday.foo.bar.messaging so it made coma sub package of com.workday.foo.bar resulting in a package of com.workday.foo.bar.com.workday.foo.bar.messaging
How would I use the simple build tool (sbt) 0.10.0 to generate any kind of source code based on an ANTLR3 grammar?
I guess I have to use a plugin for something like this, if I want to use the generated code within the same project or a subproject of the same parent project. Are there any existing plugins for SBT 0.10? ...or maybe another solution without using a plugin?
You won't need to use a plugin.
First you will need to define antlr as a dependency. Then you will need to define your source generation task according to this page:
https://github.com/harrah/xsbt/wiki/Common-Tasks
Your task definition is going to look something like this:
sourceGenerators in Compile <+= sourceManaged in Compile map { dir =>
<code to generate source from grammar files>
}
Where the code to generate your source will create a new org.antlr.Tool object with your files as an argument to the constructor. Once you have created a Tool object, then invoke the process method, and your source should be generated.
I'm currently using sbt to build and run my scala programs. I'm trying to use sbt.Process to execute system commands. I must be missing something because when I try to import sbt.Process in one of my files in src/ I get this error.
not found: value sbt
[error] import sbt.Process._
So it looks like I can't access the sbt package inside my src/ files. What do I need to do to access it? Thanks.
SBT's environment (v 0.7.x) is only available in your build file or a Plugin.
The easiest way to use sbt.Process library (until 0.9.x which will have Process as an independent library) is to copy (BSD License) Process.scala and ProcessImpl.scala into your project
There are different classpaths for running sbt and compiling your source files.
One classpath is for compilation of files in directory project/build (that one contains sbt jars and usually scala library 2.7.7) and the other one is for building source files of your project (that one contains your dependencies from lib and lib_managed and usually scala library 2.8.*). If you'd like to use sbt.Process in your source files you can do two things:
add sbt jar to lib or lib_managed for it to be available on your project's classpath
use snapshot version of scala 2.9, it would have sbt Process built-in as sys.process package
Wait for Scala 2.9, and then just use it out of scala.sys.process.
sbt package has became an integral part of the Scala standard library since version 2.9
...this API has been included in the Scala standard library for version 2.9.
quoted from sbt wiki
Here's the link (scroll down)
well, in order to use it, all you have to do (assuming you are using sbt for build), is to add in build.sbt file the following line of code: sbtPlugin := true it will add the needed dependencies to your project.
of course, this solution is only to get your imports with sbt package to work. you should refactor your code to use the new package scala.sys.process like Daniel C. Sobral suggested.