Compilation Es6 vers Es5 java maven

bonjour

j'ai fait un petit bricolage avec shift-ast
vous le trouverez ici
https://github.com/sekaijin/shift-ast-maven-plugin

l'idée est de faire un projet purement maven qui compile des fichiers sources utilisant import/export à la sauce Es6 pour produire
un fichier Es5 exécutable sur le navigateur.

C'est encore expérimental
pour l'utiliser créer un projet maven
dans
src/main/scripts
y placer le fichier main.js

Code:

1
2
3
4
5
import {b} from "./test.js";
 
var simple="1.0";
console.log(simple);
console.log(b);

y placer le fichier test.js

Code:

1
2
3
4
export var b ={
  version: 15.3,
  a:12
};

editer le fichier pom.xml pour appeler le plugin

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
 
	<groupId>com.shapesecurity.it</groupId>
	<artifactId>simple-it</artifactId>
	<version>1.0-SNAPSHOT</version>
 
	<description>A simple IT verifying the basic use case.</description>
 
	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
	</properties>
 
	<build>
		<plugins>
			<plugin>
				<groupId>com.shapesecurity</groupId>
				<artifactId>shift-ast-maven-plugin</artifactId>
				<version>1.0.0-SNAPSHOT</version>
				<configuration>
					<inputDirectory>src/main/scripts</inputDirectory>
					<mainFile>main.js</mainFile>
					<prettyPrint>true</prettyPrint>
					<outputFile>target/runnable.js</outputFile>
				</configuration>
				<executions>
					<execution>
						<id>compile</id>
						<phase>compile</phase>
						<goals>
							<goal>compile</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
</project>

compiler le projet vous obtenez le fichier target/runnable.js

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
(function(global){
"use strict";
function require(file,parentModule){
if({
}.hasOwnProperty.call(require.cache,file))return require.cache[file];
var resolved=require.resolve(file);
if(!resolved)throw new Error("Failed to resolve module "+file);
var module$={
id:file,require:require,filename:file,exports:{
},loaded:false,parent:parentModule,children:[]};
if(parentModule)parentModule.children.push(module$);
var dirname=file.slice(0,file.lastIndexOf("/")+1);
require.cache[file]=module$.exports;
resolved.call(void 0,module$,module$.exports,dirname,file);
module$.loaded=true;
return require.cache[file]=module$.exports;
}require.modules={
};
require.cache={
};
require.resolve=function(file){
return{
}.hasOwnProperty.call(require.modules,file)?require.modules[file]:void 0;
};
require.define=function(file,fn){
require.modules[file]=fn;
};
require.define("1",function(module,exports,__dirname,__filename){
var b={
version:15.3,a:12};
exports["b"]=b;
console.log(b);
});
require.define("2",function(module,exports,__dirname,__filename){
var __resolver=require("1",module);
var b=__resolver["b"];
var simple="1.0";
console.log(simple);
console.log(b);
});
return require("2");
}.call(this,this));

il n'y a aucune interprétation javascript. shift-ast compile le code source est construit un arbre syntaxique (la base des compilateur modernes)
le projet bandolier ne fait que l'utiliser pour générer un Es5
mais l'outils possède en interne de très nombreuses capacités. comme un minifier un validator etc.

enfin pour ce qui s'y intéressent WASM (WebAssembly) est une représentation binaire d'un AST. il y a quelques différences entre shift-ast et wasm-ast mais cela semble être une voie pour compiler le code ES.

j'ai utilisé l'implémentation java car j'explore différente solution pour faire des applis front back Javascript/java qui aujourd'hui font un build maven qui appelle node.js pour grunt ou autre gulp les builds de ce type sont rarement efficaces car ils divergents dans leur philosophie.

Avec maven il est possible aujourd'hui de gérer la quasi totalité de la chaine les dépendances javascript peuvent être géré via des dépendances maven en utilisant webjar. la partie purement js reste un obstacle.

shift-ast apporte pas mal d'outillage tant en js qu'en java.
pour vous donner un ordre d'idée du travail pour faire ce plugin voici la totalité du code source

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
package com.shapesecurity.bandolier;
 
import java.io.File;
import java.io.FileWriter;
import java.nio.file.Paths;
 
import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugins.annotations.LifecyclePhase;
import org.apache.maven.plugins.annotations.Mojo;
import org.apache.maven.plugins.annotations.Parameter;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
 
import com.shapesecurity.bandolier.loader.FileLoader;
import com.shapesecurity.bandolier.loader.IResourceLoader;
import com.shapesecurity.bandolier.loader.NodeResolver;
import com.shapesecurity.shift.ast.Script;
import com.shapesecurity.shift.codegen.CodeGen;
 
@Mojo(name = "compile", defaultPhase = LifecyclePhase.COMPILE)
public class BundlerMavenPlugin extends AbstractMojo {
 
	String IMPORT_FORMAT = "import '%s';\n";
	/**
         * Location of the file.
         */
	@Parameter(property = "outputFile", required = true)
	private File outputFile;
 
	/**
         * input directory.
         */
	@Parameter(defaultValue = "${project.src.directory}", property = "inputDirectory", required = true)
	private File inputDirectory = null;
 
 
	/**
         * prettyPrint.
         */
	@Parameter(defaultValue = "false", property = "prettyPrint", required = false)
	private Boolean prettyPrint = false;
 
 
	/**
         * input file.
         */
	@Parameter(defaultValue = "main.js", property = "mainFile", required = true)
	private File mainFile = null;
 
	Logger log = LoggerFactory.getLogger(BundlerMavenPlugin.class);
 
	public void execute() throws MojoExecutionException {
		if (null == inputDirectory || !inputDirectory.exists()) {
			throw new MojoExecutionException("Error inputDirectory not exists " + inputDirectory);
		}
		if (null == mainFile || !mainFile.exists()) {
			String name = mainFile.getName();
			mainFile = Paths.get(inputDirectory.getPath(), name).toFile();
			if(!mainFile.exists()) {
			  throw new MojoExecutionException("Error mainFile not exists " + name);
			}
		}
 
		try (FileWriter fileWriter = new FileWriter(outputFile);){
			IResourceLoader loader = new FileLoader();
			Script bundle = Bundler.bundle( 
					Paths.get(mainFile.toURI()).toAbsolutePath(),
					new NodeResolver(loader), loader);
 
			fileWriter.write(CodeGen.codeGen(bundle, prettyPrint));
			fileWriter.flush();
			fileWriter.close();
		} catch (Throwable e) {
			throw new MojoExecutionException(e.getMessage(), e);
		}
	}
}

le compilateur se réduite aux deux ligne de code 67 et 71
A+JYT

Quelles sont ces divergences de philosophie auxquelles tu fais allusion pour les toolchains JS ? Et en quoi ce que tu proposes n'est pas une divergence de philosophie de plus ?

Mon propos n'est pas de dire que gulp ou grunt sont des divergences. Mais que associer maven avec de tel outils est complexe car la philosophie qui est derrière chacun (maven inclus) diverge. Le principe de base de gulp par exemple est proche de ant en ce sens qu'il propose de definir un succession de tâches. Alors que maven na pas de notion de tâches.

Ce que j'étudie c'est la mise en euvre de module maven s'intégrant dans les cycles du build. Par exemple la phase generation de souce génère de classes java le css du js etc. La phase validation valide tout ca et la phase compile produit les exe enfin la phase assemblage produit de livrables.

Pouvoir ajouter des actions spécifiques a js dans ces phases ce n'est pas du tout ce que propose gulp. Qui au contraire propose de definir une chaine d'actions

Aujourd'hui pour faire cela avec maven il faut definir des morceaux de build gulp que tu envoque au travers d'un exec de node depuis plusieurs éléments dans maven.

Du coup il te faut plusieurs outils node java comme support d'exécution gulp ou grunt et maven comme builder etc.

Cela reviens a casser les idées qui ont donné naissance a gulp pour n'en utiliser que des morceaux. Le tout avec une mise en oeuvre complexe.

Ce que je cherche a faire c'est un build 100% maven pour les projets qui ont une partie back avec maven.

L'autre solution faire en sorte que gulp ou grunt soit capable de faire tout le build ce qui est un travail encore plus lourd.

A+

Dans ma boîte on a résolu ce problème en isolant complètement les parties front et back au niveau projet. Cette séparation s'est faite en même temps que la nouvelle tendance "architecture micro-services", ce qui a facilité la transition. Chaque sous-projet a sa toolchain dédiée, le front sous Gulp/Webpack, le back sous Maven. Les configurations d'environnement sont gérées via des containers Docker. Ça rend les choses bien plus simples mais c'est à réserver pour les gros projets avec de grandes équipes, car le travail de fond est plus important.