Os documentos do Webpack declaram que output.publicPathé:
A output.pathpartir da visualização do JavaScript.
Poderia, por favor, explicar o que isso realmente significa?
Eu uso output.pathe output.filenamepara especificar onde o Webpack deve gerar o resultado, mas não sei ao certo o que colocar output.publicPathe se é necessário.
Eu gostaria de acrescentar a esta pergunta: quando você usaria pathe quando publicPath?
— Wmock 22/03/16
Resposta está aqui: github.com/webpack/docs/wiki/configuration#outputpublicpath
Se ajuda: tomasalabes.me/blog/_site/web-development/2016/12/10/…
Alguém em sua equipe de desenvolvimento deve acordar. Muitos fazem esta pergunta
aqui estão os documentos para o webpack2 .
Diretório de disco local para armazenar todos os seus arquivos de saída (caminho absoluto) .
Exemplo: path.join(__dirname, "build/")
O Webpack produzirá tudo em localdisk/path-to-your-project/build/
Onde você enviou seus arquivos agrupados. (Relativo à raiz do servidor)
Exemplo: /assets/
Supondo que você implantou o aplicativo na raiz do servidor http://server/.
Ao usar /assets/, o aplicativo vai encontrar Webpack ativos em: http://server/assets/. Sob o capô, todos os URLs encontrados pelo webpack serão reescritos para começar com " /assets/".
src="picture.jpg" Reescrições ➡ src="/assets/picture.jpg"
Acessado por: ( http://server/assets/picture.jpg)
src="/img/picture.jpg" Reescrições ➡ src="/assets/img/picture.jpg"
Acessado por: ( http://server/assets/img/picture.jpg)
Quando executado no navegador, o webpack precisa saber onde você hospedará o pacote gerado. Assim, é possível solicitar blocos adicionais (quando se usa a divisão de código ) ou arquivos referenciados carregados através do arquivo-loader ou url-loader respectivamente.
Por exemplo: Se você configurar seu servidor http para hospedar o pacote gerado, /assets/você deve escrever:publicPath: "/assets/"
— Johannes Ewald
Você pode me dizer onde está localizada a pasta de ativos? Gostaria de ver os arquivos na pasta de ativos Obrigado.
o publicPath é usado apenas para fins de desenvolvimento, Fiquei confuso na primeira vez que vi essa propriedade de configuração, mas faz sentido agora que usei o webpack por um tempo
suponha que você coloque todo o arquivo de origem js na srcpasta e configure seu webpack para construir o arquivo de origem na distpasta output.path.
Mas você deseja servir seus ativos estáticos em um local mais significativo como webroot/public/assets, desta vez, você pode usar out.publicPath='/webroot/public/assets', para que em seu html possa referenciar seus js <script src="/webroot/public/assets/bundle.js"></script>.
quando você solicitar webroot/public/assets/bundle.jso webpack-dev-serverencontrará os js na pasta dist
obrigado por Charlie Martin para corrigir minha resposta
original: o publicPath é usado apenas para fins de desenvolvimento, não é apenas para fins de desenvolvimento
Não, essa opção é útil no servidor de desenvolvimento, mas sua intenção é carregar de forma assíncrona pacotes de scripts em produção. Digamos que você tenha um aplicativo de página única muito grande (por exemplo, o Facebook). O Facebook não gostaria de veicular todo o seu javascript toda vez que você carrega a página inicial; portanto, ele serve apenas o necessário na página inicial. Então, quando você acessa seu perfil, ele carrega mais javascript para essa página com ajax. Esta opção informa onde o servidor carregará esse pacote configurável a partir de
Não é apenas para fins de desenvolvedor, a resposta da @ jhnns explica como isso afeta as saídas do carregador.
é o mesmo, não é? essa propriedade informa ao seu carregador e ao seu middleware onde encontrar os ativos reais, espero que você não use o webpackmiddleware ou o webpack-dev-server em seu ambiente de produção, por isso acho que isso é apenas para o ambiente de desenvolvimento, consulte webpack.github .io / docs / webpack-dev-server.html
Nesse webpack.github.io/docs/configuration.html#output-publicpath , parece que essa opção informa ao webpack para preencher o URL ou caminho correto dos ativos nos arquivos gerados, não apenas para middlewares. Ao executar o servidor de desenvolvimento, acho que o middleware procura publichPathseqüestrar solicitações e retornar os arquivos na memória.
exatamente, em seu ambiente de produção, você usará webpack -ppara construir seus ativos, e seus ativos devem ser atendidos pelo servidor de aplicativos ou pelo servidor nginx, em vez do servidor webpack ou pelo middleware webpack, para que essa configuração não seja mais útil no ambiente de produção, estou certo ?
Não, essa opção é útil no servidor de desenvolvimento, mas sua intenção é carregar assincronamente pacotes de scripts em produção. Digamos que você tenha um aplicativo de página única muito grande (por exemplo, o Facebook). O Facebook não deseja exibir todo o seu javascript toda vez que você carrega a página inicial, portanto, ele serve apenas o necessário na página inicial. Então, quando você acessa seu perfil, ele carrega mais javascript para essa página com ajax. Esta opção indica onde o servidor deve carregar o pacote
Você pode usar publicPath para apontar para o local em que deseja que o webpack-dev-server sirva seus arquivos "virtuais". A opção publicPath será o mesmo local da opção de compilação de conteúdo para o webpack-dev-server. O webpack-dev-server cria arquivos virtuais que serão usados ​​quando você o iniciar. Esses arquivos virtuais se assemelham aos arquivos agrupados reais criados pelo webpack. Basicamente, você deseja que a opção --content-base aponte para o diretório em que seu index.html está. Aqui está um exemplo de configuração:
O webpack-dev-server criou uma pasta de ativos virtuais junto com um arquivo bundle.js virtual ao qual se refere. Você pode testar isso acessando localhost: 8080 / assets / bundle.js e, em seguida, verifique seu aplicativo para esses arquivos. Eles são gerados apenas quando você executa o servidor webpack-dev.
Como uma boa explicação, mas, em seguida, se eu mudar para a produção ou fazer a compilação com a mão /build/bundle.jsvou ter que mudar o srcno meu index.htmlarquivo certo?
Desculpe pela resposta tardia. Você não precisa alterar o src. Seja na produção ou no desenvolvimento, o webpack criará um bundle.js no caminho de saída. No exemplo acima, será /build/bundle.js.
Obrigado, estou perguntando sobre a srclinha no arquivo index.html. No momento, ele está apontando para "assets/bundle.js"a mudança para a produção do pacote, "build/bundle.js"então terei que mudar isso na linha html src para src="build/bundle.js". Ou existe uma maneira mais automatizada?
— 22617 ArchNoob
Eu entendo sua pergunta agora. Sim, você precisará alterar o src para build / bundle.js para produção. Quanto a uma maneira automatizada de fazer isso, não tenho certeza. Vi outras pessoas criarem dois arquivos webpack.config.js diferentes, um para produção e outro para desenvolvimento. Provavelmente existe uma maneira programática como se (ENV === produção) faça isso ... mas eu não tentei isso.
@ArchNoob Apenas um aviso sobre como estou fazendo isso na produção agora. Não alterei o valor src, mas alterei meu valor publicPath de /assets/para /build. Dessa forma, não preciso alterar meu index.html. Também mudei meu index.html da pasta de compilação e para a raiz do aplicativo.
no meu caso, tenho um cdn e colocarei todos os meus arquivos estáticos processados ​​(js, imgs, fontes ...) no meu cdn, suponha que o URL seja http://my.cdn.com/
portanto, se houver um arquivo js que é o URL de referência original no html é './js/my.js', ele deverá se tornar http://my.cdn.com/js/my.js no ambiente de produção
Nesse caso, o que eu preciso fazer é simplesmente definir publicpath como http://my.cdn.com/ e o webpack adicionará automaticamente esse prefixo
— Kent Wood
Parece não adicionar nenhum prefixo no meu caso.
filename especifica o nome do arquivo no qual todo o seu código em pacote será acumulado após a etapa de compilação.
path especifica o diretório de saída em que o app.js (nome do arquivo) será salvo no disco. Se não houver diretório de saída, o webpack criará esse diretório para você. por exemplo:
Isso criará um diretório myproject / examples / dist e, nesse diretório, ele cria app.js , /myproject/examples/dist/app.js . Após a construção, você pode navegar para myproject / examples / dist / app.js para ver o código em pacote
publicPath: "O que devo colocar aqui?"
publicPath especifica o diretório virtual no servidor Web de onde o arquivo compactado, app.js será distribuído. Lembre-se de que a palavra servidor ao usar publicPath pode ser webpack-dev-server ou express server ou outro servidor que você possa usar com o webpack.
essa configuração diz ao webpack para agrupar todos os seus arquivos js em examples / dist / app.js e gravar nesse arquivo.
publicPath diz ao webpack-dev-server ou express server para servir esse arquivo em pacote, por exemplo, examples / dist / app.js, a partir do local virtual especificado no servidor, por exemplo, / public / assets / js. Portanto, no seu arquivo html, você deve fazer referência a esse arquivo como
Portanto, em resumo, publicPath é como mapear entre virtual directoryno servidor e output directoryespecificado pela configuração output.path. Sempre que a solicitação do arquivo public / assets / js / app.js vier, o arquivo /examples/dist/app.js será exibido
— shrestha udeep
A documentação do webpack2 explica isso de uma maneira muito mais limpa: https://webpack.js.org/guides/public-path/#use-cases
O webpack possui uma configuração altamente útil que permite especificar o caminho base para todos os ativos em seu aplicativo. É chamado publicPath.
publicPath é usado pelo webpack para o caminho relativo de substituição definido em seu css para referenciar imagem e arquivo de fonte.