Pregunta Yeoman Workflow e integración con scripts de back-end


Entonces, he estado anticipando Hacendado y ya ha salido durante una semana más o menos. Pero luego de instalarlo con éxito, me confundí en el flujo de trabajo y la implementación con el script back-end (API).

escenario 1

Así que digamos que no necesito todas esas cosas brillantes de BBB / Ember / Angular y uso Yeoman solo para jQuery / H5BP / Modernizr respaldado con Codeigniter o Sinatra / Rails. Ya que yeoman server no es compatible nativamente con PHP (no he probado Sinatra / Rails), me imagino que el flujo de trabajo es:

  • Desarrollo de front end con Yeoman
  • Después de que haya terminado, hazlo yeoman build y luego usar el construido dist carpeta como base para desarrollar backend (y probablemente copiar el dist carpeta a otra carpeta para la implementación de back-end (digamos public carpeta)
  • Si tuviera que cambiar CSS / JS, use yeoman nuevamente, construya y copie dist carpeta para public de nuevo. Y así sucesivamente ...

Pero al usar ese flujo de trabajo, eso significa que la estructura del directorio será algo así como

cool-app/
--app/
  --yeoman development stuff
--test/
  --yeoman development stuff
--dist/
  --yeoman built stuff
.dotfiles
package.json
Gruntfile.js

Es bueno y todo, pero bastante diferente con la estructura del directorio CodeIgniter / Rails. Sin mencionar que hay una diferencia de nombre (¿Es esto configurable en Yeoman?), por lo que es un poco difícil imaginar un buen flujo de trabajo que desarrolle Front End y Back End de una sola vez, excepto que use el resultado creado como base para el back-end.

Escenario 2

BBB / Ember / Angular. Francamente, he estado probando esas cosas, ¡así que cualquier consejo para implementar con código de backend es bienvenido! Aunque, por lo que sé, yeoman puede generar los archivos necesarios para ese marco dentro de la carpeta de la aplicación, así que supongo que la solución del primer escenario resolverá un poco el problema para el escenario 2

¡Muchas gracias!


32
2017-09-20 08:29


origen


Respuestas:


Me gusta usar esta estructura:

rails-app/
--app/
  --views/
    --js/
      --app/
      --test/
      --Gruntfile.js
--public

Así es como lo configuré:

  • rails new rails-app
  • cd rails-app / app / views
  • mkdir js
  • cd js
  • yeoman init ember

Luego edita Gruntfile.js para cambiar "output: 'dist'" a "output: '../../../public'"

Después de eso, "yeoman build" o "yeoman build: dist" saldrá a la carpeta Rails / public.

Durante el desarrollo, aún puede usar "servidor heredero" para ejecutar yeoman en modo de desarrollo, por lo que cualquier cambio que realice será automáticamente visible en el navegador.

Yeoman es genial!


37
2017-09-25 13:12



La respuesta de Sanford también funcionará para Sinatra, por supuesto, pero hay una solución ligeramente diferente que se puede usar para que no tengas que emitir "compilación yeoman" para ejecutar en modo de desarrollo.

En Sinatra, la carpeta pública es configurable, por lo que puede tener un bloque de configuración que se ve así:

configure do
    set :public_folder, ENV['RACK_ENV'] == 'production' ? 'dist' : 'app'  
end

Luego usa tus rutas de esta manera:

get '/' do    
    send_file File.join(settings.public_folder, 'index.html')  
end

Esto supone que "yeoman init" se ejecutó en la carpeta raíz de la aplicación Sinatra.

Todo lo que haces entonces es asegurarte de haber ejecutado "build yeoman" antes de implementarlo en un entorno de producción, y se usará el contenido optimizado por yeoman.


3
2017-12-29 09:02