ES6 y el futuro

[lupomontero]

Ahora que tenemos varios cursos en vías de desarrollo, nos damos cuenta de que en varios aparecen "lecciones" sobre ES6. Lo cual puede resultar en bastante overlap, además de darles a las lecciones un sabor un poco a manual de referencia... 👅 📖

Hace un tiempo conversamos sobre si deberíamos incluir ES6 desde el principio, y después de varias conversaciones el consenso parece ser que sí, así como incluimos HTML5 y CSS3. Creo que tiene más sentido enfocarse en el JavaScript de mañana que en el de ayer. Cómo referencia, en junio de este año TC39 publicó oficialmente ES8 (ES2017) y el año que viene se publica ES9.

Siendo éste el caso, propongo no incluir lecciones específicas sobre ES6 (ES2015), sino implícitamente a lo largo de "todas" las lecciones donde aparezcan features relevantes. A lo que me refiero es que por defecto mostremos el lenguaje en versión ES6, pero cuando usemos features específicos de ES6/ES7/ES8 (no soportados por motores de JavaScript antiguos) simplemente hagamos una mención y apuntemos a la documentación oficial u otras fuentes (que hay muchas muy buenas). De esta manera nos podemos concentrar en los ejemplos, challenges, ejercicios y productos...

Qué opinan?

cc/ @chamodev @ivandevp @brecabal @merunga @milmazz @Laboratoria/developers

[merunga]

mi +1 siempre a ES6

Entonces nodejs v7 y en ES6 nos quedamos?
o webpack + babel para estar preparados para ES7 y mas alla?

[iamblancaperez]

+1
Podemos redactar un "readme" para anotar las convenciones que vamos usar

[milmazz]

Totalmente de acuerdo, hasta ahora en las lecciones he venido incluyendo ES6 y los listings generalmente incluyen el API de Jest:

const curryIt = (uncurried, ...args) =>
  (...newArgs) =>
    uncurried.apply(this, args.concat(newArgs))
	
const greeter = (greeting, separator, emphasis, name) =>
  `${greeting}${separator}${name}${emphasis}`

test('should return a curried equivalent of the provided function', () => {
  const greetHello = curryIt(greeter, 'Hello', ', ', '.')

  expect(greetHello('Heidi')).toBe('Hello, Heidi.')
  expect(greetHello('Eddie')).toBe('Hello, Eddie.')
})

Hasta ahora he venido usando la siguiente configuración:

# .editorconfig
root = true

[*]
end_of_line = lf
insert_final_newline = true

[*.js]
charset = utf-8
indent_style = space
indent_size = 2

Y uso ESLint para verificar con el siguiente .eslintrc:

{
  "env": {
    "jest": true
  },
  "extends": "standard"
}

[giancorzo]

@lupomontero @milmazz @onlyblank Me parece que es bueno documentar el uso de es6 en todos los ejercicios de la curricula. ¿Por favor podrian crear un documento explicando como hacer que todos los ejercicios sean consistentes?

Aqui el enlace de la wiki donde vamos a empezar a documentar decisiones como estas

https://github.com/Laboratoria/curricula-js/wiki

[milmazz]

@giancorzo Lo primero que se me ocurre para automatizar el proceso es extraer el código JavaScript dentro de los fenced code blocks (asumiendo que el formato Markdown es gfm) y luego con ello alimentar a ESLint. El cliente de ESLint provee la opción --fix y con un archivo de configuración podrías hacer algo así:

$ script_que_extrae_fenced_code_blocks | eslint -c ~/.eslintrc --fix --stdin

Sin embargo, al intentar lo previo me encontré que no puedes usar el flag --fix junto con --stdin por ahora. Por lo tanto, tendrías que hacer un fichero intermedio, alimentar a ESLint y luego leer su respuesta y reemplazar los fenced code blocks. Lo que tendría que coordinarse es la serie de reglas que promuevan el uso de ES6 (e.g. prefer-arrow-callback)

HTH

[lupomontero]

Gracias a todxs por los comentarios. Cierro este issue por el momento y queda pendiente un issue en el parser para correr ESLINT en los bloques de código JavaScript.

[lupomontero]

Dejo también link a la página del wiki donde se mencionan las guías de estilo seleccionadas para JavaScript