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

Question

Por lo tanto, he estado anticipando Yeoman 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 todos aquellos brillante BBB/Ember/cosas angular y el uso de Yeoman sólo para jQuery/H5BP/Modernizr respaldado con CodeIgniter o Sinatra/rieles. Desde yeoman server no soporta de forma nativa de PHP (no he probado Sinatra/Rails), calculo que el flujo de trabajo es:

• Desarrollo Front End con Yeoman
• Después de que haya terminado, haga yeoman build y luego usar el construyó dist carpeta como base para desarrollar backend (y probablemente copiar la carpeta dist a otra carpeta para la aplicación backend (digamos public carpeta)
• Si tuviera que cambiar CSS/JS, utilice Yeoman de nuevo, construir y copiar la carpeta dist a public nuevamente. Así sucesivamente ...

Pero el uso de ese flujo de trabajo, eso significa que la estructura de directorios será algo así como

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

Es agradable y todo, pero un poco diferente con el/los carriles estructura de directorios CodeIgniter. Por no mencionar que hay una diferencia de nombre (es esto configurable en Yeoman?), por lo que es 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 aplicaciones, así que, la solución del primer escenario resolverá un poco el problema para el escenario 2

¡Muchas gracias!

Answer 1

me gusta usar esta estructura:

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

Así es como lo configuro:

• carriles nuevos carriles-APP
• cd carriles-app/app/views
• mkdir js
• cd js
• yeoman init ember

luego editar Gruntfile.js a cambiar "de salida: 'dist'" a "de salida: '../../../public'"

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

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

Yeoman is great!

Answer 2

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

En Sinatra, la carpeta pública es configurable, lo que puede tener un bloque de configuración que se parece a esto:

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

A continuación, utilice las rutas de la siguiente manera:

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

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

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